Wednesday, November 30, 2011

iOS Scope Bar for searches

I was cheating a bit for searching in our app. There are two columns in many of the tables - Code and Description. Most of the time the Doctors would search on the code but occasionally they want to search on description to find something like "liver abscess". To keep screen space at a premium I had the hint text tell you to type a leading SPACE to search by description. Of course that is not totally obvious and many don't read the text.

When I hit the tablet side of things I did two search fields on the Android like this:

Code: [           ]      Description: [                                   ]  [x]

You could fill in one or the other and I blank the one you are not using. Works nicely and there is plenty of horizontal space in either portrait or landscape to pull that off. Codes are small so that entry field eats up less horizontal space.

On the iOS side I am using the UISearchBar and it supports only one entry field. I was going to give up on doing the dual search on the iPad but then I discovered the scopeBar and associated methods on UISearchBar. You can set various button titles and that allows the user to toggle the type of search they are doing.

It works and I have converted the code to use it but there is a bit of oddness to it. First the toggle buttons always appear below the search bar. It would be nice to move the buttons to the right of the search bar on the iPad as I only have two buttons in most cases and plenty of screen space. Might as well show more search results. This makes for some very long toggle buttons on the iPad.

Second you can toggle the search mode then tap to type the text but once you do that the toggle buttons are disabled. You have to cancel the search, change the toggle button, restart typing your search if you entered in the wrong mode. Seems this is all one control so why disable part of it?

To save space on the iPhone it would be nice if the toggle buttons only appeared after you invoked the typing of search text. Right now they waste a lot of screen space on that small screen for the ability to toggle which is probably not used very often.

Finally there is only one keyboard mode for the entire search bar. I want it to be in numeric mode if they are doing a Code search and in alpha mode if doing a Description search but I can't do that. If my search involves Code / Description instead of Last Name / First Name I start in numeric mode but they have to manually toggle back to alpha mode to type description. I covered the 95% case here but wish I could cover 100% instead.

While initially I was happy with Apple for providing a generic search control I ended up frustrated due to its lack of flexibility. On the Android I started out thinking "Where is a generic search widget?" Implementing one was easy enough but I should not have needed to do that. I ended up with an exact layout for my needs and more flexibility in the end under Android. Typical programming issue that occurs when you are developing on multiple platforms.

Tuesday, November 29, 2011

Xcode is still crappy

I keep crashing Xcode. I have an M file open and intellisense pops up. I do the three finger swipe to switch to the H file and it crashes. I lose the work since my last save. This happens at least once a week. So stop doing that the Doctor says. I switch between my PC using Eclipse and Xcode on the MacBook Pro multiple times per day.

I don't remember crashing Eclipse in a long time. I just use the IDE and it works. Then I get on the Mac to convert over some Android code I just wrote and I forget it crashes and boom I crash it yet again. Would be nice for Apple to fix this one but I have doubts it will happen as Xcode does not get updated very often. Sure they tie in a new iOS release but the IDE itself does not change much.

Just rebooted the Mac after an update install and crash, did not notice update was ready until Xcode died. Time to go back over and see how much of my work it lost this time.

Wednesday, November 23, 2011

iOS 5.01 and WiFi - not happy

The iPad 2 I use for development and testing has been acting flaky. It is WiFi only and the connection comes at goes at will. I sit about 12' away from the wireless router. I had no issues at all until the 5.0x updates but since then it has been iffy at best. Searching the web and I found a lot of other people having the same issue. The Android tablet, also WiFi only, has had no issues.

On another Apple note the Java 1.6 update 29 caused us all sorts of memory leaks. Our clients could run our Java program on the Mac for about 15 minutes before running out of memory. No issues on the PC or Linux with update 29, just on the Mac. My boss dug into their bug fix and fixed their fix to release the objects properly and we are back in business. We checked in our overridden code to our project so our users are not hosed. Others on the web are complaining about this issue too.

I am also able to crash Xcode 4 at will. Edit M file, have intellisense / code complete / whatever they call it pop-up, three finger swipe to got to the H file and crash city. I have used the reporting tool to send this off to Apple. Happens to me at least once a week. They tend not to release fixes to Xcode unless they are doing a new iOS release so I bet this is not fixed in the near future.

Low hopes of the Java bug being fixed soon either. It has been a long time for a Java update - going from 26 to 29 - so I bet this hangs out there for a long time too. We don't find Apple to be all that developer friendly so you just suffer along and know how to work around things.

Winding down the round of mobile app development. I pretty much have the two in sync again. Pushing a gig of code on both sides. I added long press to do some default actions. My graphic artist / Mac buddies find most users have no idea a long press exists so I made sure there is a way to get to same functionality via another part of the UI. I just consider the long press a short cut but once you get used to it being there you really like it.

User beta feedback has been very positive. Almost no bug reports, just feature requests. Some of the features make sense and I have been able to quickly add them. Some are borderline insane so they are on a "do it later if ever" list.

I sat down and rethought the way I was doing favorites and got it working the same on both iOS and Android. Pretty happy with the final results and ready to see what the beta crowd thinks of it. I have also made some graphical tweaks to the new menu system to make it look better.

I cleaned up some bugs in the iToast code I got off the web to do Toast notifications on the iPhone. If I set the gravity to top or bottom it was not painting correctly in landscape mode - the mode I generally have the iPad in. I kind of cheated here. The Android Toast code handles multiple Toasts by queuing them up and showing them one at a time. The iOS version just painted them on top of each other. I was going to write the queue code and then found I could just set the screen position instead so I have the refresh message show up on the bottom of the screen and other messages in the middle. Avoids the overlap without a ton of work on my part. This only happens in one situation where you save a case and are coming back to the case list screen. One message is saying "Case Saved" and another "Case List Refreshed". No need to introduce complexity to solve one off needs.

More than ready for the Thanksgiving break. Thus all the polish work for this short week. Might as well leave it in a very stable state so I don't think about it over vacation. I ran the memory leak detection of Xcode and cleaned up all the issues I found. Always good to run that from time to time.

Wednesday, November 16, 2011

Android / iOS sync continues

I sure thought I would be done with the next version of our application by this time but we came up with a number of new features to add before it leaves the Beta stage. I have been adding support for favorites so the Dr. can toggle which CPT / ASA / Diagnosis and other fields quickly just using the ones they use the most.

One of the benefits of dual development is it forces you to look at problems from different angles. I had the favorites all set up on the Android side of things and the Beta clients for those devices have been using it and it appears liking it. What I did on the Android does not fit naturally on the iPhone as far as UI goes.

First off I had to take some time to write a new menu system for iOS to emulate the one I am using for Android. After getting past the initial scare of creating a full blown custom menu under iOS it went rather smoothly. My draft version proved I could do a menu that pops up over another view - including tables - but the graphics design did not pan out well on an iPhone, it looked fine on the iPad. I took a step back and redesigned the menu GUI so it worked great on both device form factors in both orientations. This is a universal binary so the same code is running on both devices.

Many tweaks later I have the menu system running in a lot of places in the UI. Without that I was not going to be able to pull of the favorites as designed. Here is where I ran into the next issue. I was using my menu in two ways on the Android to do favorites, one menu to select a mode and one menu to select which items to be in the favorites list. This would not play well under iOS. I also had allow the user to control the font size under iOS and its current UI left something to be desired. After taking a step back, many head scratches and many pen scratches on paper I came up with a new single menu system that is much cleaner and easier for the user to grasp and solved the font sizing issue too. I just finished phase one of my implementation on iOS and am pretty happy with it. Now I have to convert those ideas back over to the Android which technically should not be difficult but will be time consuming as I have to touch a lot of code.

Because I needed to make something work on the iPhone my Android users will have a better experience. This has happened in both directions as there are areas I wrote on the iPhone first and during my Android conversion I discovered better ways to accomplish the same thing. Some of it comes from just wanting to get something running but when you have to write the code a second time you think it through again and make it better. That has happened over and over during this process. I have deleted, modified and bug fixed a lot of code as I go back and forth between the two platforms. At times it feels like you are just spinning your wheels and will never get it all done. Heck it is not all done but I am in the home stretch.

I often wonder what it would be like if there was another developer working on iOS. Would we be able to come up with ideas together that work well on both devices? If you don't code on both do you have blinders on for the one you don't code under? Is it better for one developer to hash out an idea and get a working prototype and then show it to the other so they can shoot holes in it and make it better? You could have each developer tackle a non-overlapping area then swap ideas. Working on the same area at the same time, unless you are following a foregone UI pattern, seems a waste of effort.

There are a lot of "Oh man, I have to write this AGAIN!" moments when you are the sole mobile developer. At times you dread writing a tough hunk of code in another language using another IDE. Not sure if I am sold on the universal binary idea for iOS. Sure it beats a 2x version of your iPhone app on the iPad but Xcode / Interface Builder don't make is very easy to have NIB files per platform. It is easy to do on Android, just use same named XML files in different directories and everything is handled for you. I have a lot of IF checks for the iPad in the code already and am not looking forward to more of them. We might be getting close to the point of doing dual development there which would make my work load even more insane.

Tuesday, October 25, 2011

Fun with Android DatePicker and 1970

I was doing a new round of testing on our Android tablet. The application is used for medical information entry and one of the fields is date of birth. It has been working like a champ on the phones using 2.01, 2.2, 2.3 but on the tablet running 4.1 you could not enter anything before 1970. You could type in 1963 and it would set it back to 1970 and the [-] button would disappear.

I totally get why it stops at 1970 as that is the epoch year used for all sorts of things in computers. Obviously the Android team changed a default in later versions of the SDK. My phone, running 2.2, allows you to go back to 1900.

After some research I found a solution that works for all devices I have tested against. In my XML file I added android:startYear="1900" to my definition. If you look in the latest documentation they discuss android:minDate but that is only available in later version of the SDK.

Before I stumbled upon startYear I tried to use reflection to call the setMinDate(long) on the datepicker but I did not have any luck doing that. I am really happy that was not the solution. I would much rather use something in the XML that solves it on all platforms.

Of course after I did this SVN got confused about a directory already being locked and would not allow me to check in the change. I found Team -> Cleanup in Eclipse solved that issue.

Now that I have my new "set favorites" processing in place on the Android I need to convert all that work over to the iPhone / iPad. Research time as some of it just does not have a direct translation to iOS and while the menu system is possible on the iPad it is officially not supported on the iPhone so I am going to have to come up with a work around. The first menu system I found has caused apps to be rejected by Apple due to private method usage making it a non-option. Dual iOS / Android development has a lot of headaches.

Wednesday, October 19, 2011

ADT 14 breaks Eclipse 3.7 - FIXED

Just to make sure my week goes as smoothly as possible I installed ADT 14 / SDK 14 for the new Android 4.0 build and now I can't build anything on my Win7 64bit box.

First I installed the new SDK. Then I installed the new ADT after I got some errors. Now I just get an error that my project has errors but not a single window will tell me what the error happens to be. I installed the SDK from scratch and still have the same error. I installed a fresh version of  Eclipse 3.7, ADT 14 and SVN plug-ins and still have the same issue. I have run every update possible. Our bandwidth sucks right now so this is taking a really long time and I am getting really tired of experimenting. I will have to give this a try at home to see what happens there tonight.

I did cleans before I did builds and did the Android -> Fix Project menu item but nothing will get me past the error message that I have a project error but nothing will tell me what the error is. Not a single file, other than the main project, is marked as in error. I see others are having the same issue on the web. I looked in the project properties and nothing is showing up as in error there either.

At this point I am running Eclipse on my Mac as it has not been updated to 14. No idea what to do next. I just got out of the iTunes / Xcode / iOS 5.0 install hell. At least that is all working. Now I get to be really annoyed at Google / Android from screwing this up. Guess I can blow away all the version 14 stuff and go back to 13 to see what happens. Seems this is all a bit rushed.

Well not the fault of Eclipse or Google on this one. My developer certificate happened to expire at the exact same time I installed the update. Once I deleted the old certificate off my HD an let Eclipse build a new one all was fine. Somewhere in there showing errors in the Problem tab had gotten turned off - it was only showing warnings thus it looked like nothing was wrong. What a huge waste of time and energy it took to figure all of this out. I wish the error message would show your the current error list instead of just saying "there is an error, good luck finding it!"

Friday, October 14, 2011

Pains of iOS 5.0 from a developer perceptive

We needed to test our app under iOS 5.0 so I began that process yesterday.

Step 1: Download and install new iTunes
Success - no issues

Step 2: Connect iTouch Rev 4, install iOS 5.0
Success - but blew away everything on device. I only use it to test, not a big deal.

Step 3: Install and run app on iTouch
Failure - Xcode does not know about iOS 5.0 devices so it refused to install. I find this to be stupid as the target of device of the code is 3.0.

Step 4: Download and install Xcode 4.2 for Snow Leopard
Success / Failure - Takes a long time to get it but it installed. Install works but it blows away all SDK version prior to 4.0. I can't test with a 3.2 simulator at this point. Xcode 4.2 has some new warnings that are valid. I fix those issues in the code while I am fixing the iOS 5.0 issue.

Step 5: Install app on iTouch
Success - it now will install

Step 6: Test app on iTouch
Failure - it crashes because some really old code is using NSIndexPath passed to didSelectRowAtIndex path call later. I need to copy and retain the data to solve the issue. Never a good programming idea in Objective C to think any variable passed to you will hang around. No other version of iOS cared about this particular one. Could be they fixed some things to get ready for dual core processing or other threading issues.

Step 7: Check in changes
Failure - Xcode "sees" SVN for a brief second then gets lost. Use IntelliJ AppCode to check in changes. Find out I need put the URL to our instance of SVN into Safari. Safari bitches about certificate but I can tell it to stop bitching then Xcode starts to work. Xcode SVN interaction has always been spotty at best and again it bites me in the behind.

Step 8: Archive for app submission
Failure - Xcode can't find my deployment provisioning profile. Delete profiles, refresh, rebuild,  restart Xcode, pray, etc. Something finally works and I can set the deployment area to the proper profile. Archive menu item is disabled. Search Google and remember that you must select iOS Device as target for this to be enabled. Remember how stupid that is from the last time this happened to me so many months ago.

Step 9: Validate
Failure - Message tells me it can't find the app in iConnect. Google the message and see that I have to have the app in "waiting to upload" state before it will validate it. Next step will be for the boss to do that so I can try again.

Step 10: Test on iTouch without iOS 5.0
Failure - By default Apple has decided that anyone not running on a armv7 device should just throw the worthless piece of crap in the trash and give them more money. Connect device, press RUN and all you get is a message that it finished running on the device even though it did not install or run. No error, no console, no help - thanks Apple. You have to open up the build settings and add armv6 back into the supported architectures then it will run on the device just fine. If you only test with the simulators you would not find this issue as the simulator is i386 architecture and I was able to run all the way back to 4.0 using that. After installing Xcode 4.2 you would be hosed unless you tested on physical devices.

Step 11: Submit to store
Success - Once the boss got the app in "ready to submit" mode I was able to validate and submit it without any issues. The error message was stupid. We also put up new screen shots for both the iPhone and iPad.

Step 12: Released to market
Success - It only took Apple two days. I was expecting 10. Kudos to Apple for cranking this one out. Last time it took 7 days and I figured they would be swamped. We did put in the notes that it was an iOS 5.0 fix being released. Between that and small download count I am sure they just pushed it through figuring if we screwed the pooch on this one it would come back to haunt our users and us but not really Apple.

A huge waste of time this has been. What you need to do is not obvious. The new updates from Apple are not friendly and blow away or break things. Apple is rather developer hostile. I need to get the app submitted to the market as it is broken under iOS (our fault, not Apples fault). With a rash of people submitting to Apple right now for iOS 5.0 who knows how long I will be in the queue. All our current users who upgrade will be hosed. This is a huge failing of the Apple Store. I will not be able to get a couple of line fix out to our customers in a timely manner.

Xcode continues to be a very annoying IDE. If this is what Apple considers a good UI and user friendly then I don't want to know what they are like when they are mad at me.