Google+ Badge

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.