Archive for July, 2010
I like Google Maps. What I don’t like — these maps are not available offline, which is exactly the time I need them most of all, far away from home and, probably, without a reliable phone data connection. Actiually, there might be some way to cache Google Maps, and I’m sure my phone does that, but I could not figure out how to get it working reliably, it feels like cache time is very limited, maybe hours or minutes — definitely not enough for real-life applications.
Recently I’ve found Maverick from Code Sector. It shows the map, works with GPS and compass and does pretty much everything Google Maps does, and also it can cache and use offline maps. There’s even explanation about how to download and where to save map tiles.
However, the map downloading software just downloads everything within the selected region and did not care much if there’s real map data or just plain sea (Japan consists of many islands), so I did not want to end up with numerous files with blue color inside and used my own downloader.
Fortunately, I have already downloaded plenty of Google Maps for offline use with some other software, so I did not want to redownload everything again, and just needed a way to reconvert and save map tiles appropriately for Maverick.
Maverick uses the following path for Google Maps : /sdcard/maverick/tiles/googlemaps/0/0/0.png.tile, I just need to figure out what are those numbers and how should I place my files there.
The first number is obviously zoom factor. Google Maps saves maps according to the zoom factor, the lowest zoom level is 0, which gives us 20 = 1 tile, covering the whole globe. Next zoom level 1 splits the globe into 2×2 = 4 tiles. Zoom level 2 results in 4×4 = 16 tiles. And for any given zoom level z we can calculate the number of tiles covering the whole globe as NxN, where N = 2z. Google Maps has only 17 zoom levels for maps, and maybe 19 for satellite images.
If we have latitude and longutide, the tile number can be calculated with the following code snippet (in Python) :
def coord2tile(lat_deg, lon_deg, zoom): lat_rad = math.radians(lat_deg) n = 2.0 ** zoom xtile = int((lon_deg + 180.0) / 360.0 * n) ytile = int((1.0 - math.log(math.tan(lat_rad) + (1 / math.cos(lat_rad))) / math.pi) / 2.0 * n) return(xtile, ytile)
And in the Maverick the X coordinate becomes the folder name (inside the zoom folder) and Y coordinate becomes the file name (sans ‘.png.tile’ extension), so the proper place for Google Maps tile is /sdcard/maverick/tiles/googlemaps/ZOOM/X/Y.png.tile
The whole world at zoom levels 4~6 does not take much space at all, whole Japan at zoom levels upto 13 is about 200mb, and some areas of interest, like Tokyo and Osaka at zoom levels up to 15 add about 800mb, so whole map of Japan takes about 1GB of map tiles and fits to 4GB of memory card (it takes more space on SD card because of large cluster size).
Predownloaded Google Maps
Whole world, zoom 4~6 (17mb) :
Japan, zoom 7~12 (140mb) :
Japan, zoom 13 (200mb) :
Levels 14 and beyond take too much space, so you may download partial maps around the places you like yourself.
Also, be careful, if your SD card is formatted with 16kb cluster size, maps tend to occupy 3-4 times as much space as their size. 1GB of maps took about 4GB of space on my device, so if your SD card is small, it might be a good idea to format with 2~4k cluster size.
Softbank has decided to stop accepting orders for HTC Desire from Jul, 29th. Instead they brought out a press-release about “Desire II”, with LCD screen instead of OLED (probably because of Samsung OLED display shortage).
There are SMS messages, which can contain about 160 characters. Japanese uses multi-byte encodings, so the actual character count is much lower. Also, people like to send pictures taken with the built-in cameras, music and other things which don’t fit well into 160 byte limit.
Therefore, MMS (multimedia messaging service) was born. It works like this: you get a short SMS message using SMS protocol, and then your phone has to use data connection to receive the rest of the message from the server. SMS messages work everywhere, but ways and protocols for retrieving the actual message are different from one provider to another. If these protocols are not followed, only “subject” line of MMS message will get through, which is actually delivered via usual SMS.
This is why we need specially tailored application to receive MMS messages on softbank, another specially tailored app to receive MMS messages on DoCoMo and so on. Also, this is the reason, why originally iPhone did not support MMS (it was added about a year later) and why HTC Desire still (oficially) does not support MMS, however there are a few versions of custom-made software, which, more or less, aleviate this problem.
It’s very distracting, but every time HTC Desire lost signal for a while, it tries to reacquire time information and for some unknown reason there’s no TZ info included. There’s no solution for this problem, except moving to the area of better reception quality. Native SB firmware has the same problem.
I’ve found wonderful gem on android forums:
Just took my A8181 which I got from HK to Softbank after flashing one of the ROMs above, shop people confused for a bit as IMEI wasn’t in their “stock database” but eventually caved in and gave me a sim w/smartphone data plan.
They spent about 30 minutes poking around the phone, comparing it with the plastic model they had in store “hey why it says softbank here and only says HTC on this one??” and had to make a few calls to their boss to confirm. I *think* i heard them mumble “rooted”? once before but I’m not sure the guy was too far.
I’m sure I would have to get a 2 year contract with a useless phone otherwise, just to use it’s sim.
Looks like there’s hope to get imported phones to work legally in SB network.
By Rick Rogers, John Lombardo, Zigurd Mednieks, G. Blake Meike
Publisher: O’Reilly Media
Released: May 2009
Very nice “no-bullshit” introduction book. A little bit dated, because it’s based on SDK v1.1, and Android development went far ahead since 2009. Also, some of the examples don’t run ‘as is’ with the current SDK, but actually it’s not very important (who runs them anyway?), because the main point of this book — a very concise explanation of Android internals and development process. Explanation, which don’t dig very deep into the unnecessary details, but tells everything you should know to develop for Android. Well, maybe not everything, but just the right amount to get started, including the basic work-flow scenarios and solutions to common problems.
People with no computer background may find this book a bit difficult to read, because there’s no gentle introduction to every aspect of computing and programming, but for someone with even a little experience in computers who tries to jump into Android software development it’s a must have.