I have set up the Android SDK and emulator for the BA on the project. This has been a great help. She can test the program without a physical device and can grab screen shots for documentation. It has not been great in that the emulator snapshot functionality has bitten us repeatedly.
Why use snapshot? If you don't it takes a long time for the emulator to fire up. Not very friendly when someone stops by for a quick demo. I think the best settings are as follows:
- Tell the virtual device you want to use snapshots on its edit screen or when initially created
- Start emulator and tell it to "save to snapshot" on exit
- Once it starts turn off Japanese keyboard stuff (not sure why this is on by default always)
- Install your APK files via adb
- Shut down emulator
- Start emulator, select "Launch from snapshot" and turn off "Save to snapshot"
If you continually have it save to snap shot it will corrupt the snapshot at some point. This has happened to me repeatedly. The second bit of fun, when you delete a device it does NOT delete the snapshot. This means if you delete the device then create a new one with same name you get the old corrupted snapshot to kick in. You can manually delete them in the {user dir}\.android directory. The AVD manager should really take care of this. This does mean when I update the APK I need to get a new save snapshot after I install it. Means I can't automate that process which stinks.
I added a menu to the Android app with and About and Logout buttons. Very easy to do and I love having access to a menu button always on the phone. It also makes it easy when you are helping someone with their device - "Hit the menu button" is easy but "Find the menu somewhere on the screen or get out of the app and go all the way back to Settings to see if there are settings for the app you just closed somewhere in there" is not as friendly.
On the iPhone side you are on your own when it comes to coding. I decided to add a button to the title bar off to the right. On the iPhone the left side is used for the "back" button, the middle for the name of the current view. Makes more sense to me to have the back and menu buttons off the screen the way the Android did it but on the iPhone you have a bit of text telling you where "back" will go. Of course you can do the same thing on the Android if you so choose, Apple just does not give you a choice, one button to rule them all! Reminds me of their battle to avoid two button mice for the longest time.
What should logout do? Turns out closing an app on the iPhone will get you rejected from the app store so that is not an option. Returning you to the login screen appears to be the way to go. On the iPhone the user MUST be the one to press the HOME button to close an app. Of course that does not really close the app anymore depending on what device you use but we better not use the fragmentation word as it only applies to the Android right?
I spent a good deal of time this morning on Stack Overflow to find this line of code:
[self.navigationController popViewControllerAnimated:NO];
When they select logout from the popup menu the view needs to close. Not that I would have figured out this line by scanning the API documentation. At least it is one line of code and not too contorted. I then added a global variable (shudder) to the main control so each view could check that and if we are in the process of logging out we also close ourselves during the view will appear processing. When we hit the Login screen it does not close but instead just clears the variable. Working like a champ during my testing.
This does bring me back to the evil "fragmentation" word. It is thrown at the Android side of things all the time due to screen resolution and other hardware differences. Yes, I have code in my app to handle these differences. No, it is not fun to write and test. Yes, I have an emulator that helps. No the emulator is not a job to work in.
What about on the Apple side? You have various OS versions with some being multitasking and others not. Just tell them to upgrade right? Wrong, some are now stuck at a revision. The second generation iTouch that I use for testing just got added to the stuck list. I already have code in place to check for multitasking in our app. I have been affected by iOS fragmentation.
The new iPad is said to be really speedy compared to the old one. I had lunch with a friend yesterday who expressed concerns with their iPad app and timing issues. Even the simulator in Xcode now lists multiple options - iPad 3.2, iPhone 4.0, iPhone 4.1, iPad 4.2 and iPhone 4.2. They just released GM of 4.3 so I will need to grab that too. The simulator runs a ton better on the Mac than the Android emulator on the PC but it also gives a false sense of speed.
Let's just kill the fragmentation rhetoric. It affects every developer no matter the platform. We have dealt with it for years. It is affecting Apple more than they care to admit. It may limit them from doing a smaller screen iPhone nano. I know not to hard code to screen resolutions but I do see sample code that does on various websites when looking up iOS issues.
You can tell me tablets and phones are different beasts and I will agree. You should not just scale up your phone interface for the tablet, it should become a new fuller featured interface instead. That is one of the early bitches about the Xoom, not enough native applications. Even tossing them into two buckets you still have fragmentation due to iOS differences due to lack of upgrade options. I don't want to see these old devices in the landfill.
Both Apple and Android have fragmentation. It should no longer be listed as a Pro or Con when deciding with camp to join. End of rant.
No comments:
Post a Comment