I do both iOS and Android development thus I have a MacBook Pro has my main development device. I have had one for the last 3 years. Since upgrading to Yosemite it has become the least stable development box I have worked on in a long time.
I leave the machine on and lock / put it to sleep when I am away from my desk. This may be going to a meeting, going to lunch or home for the evening. When I come back from lunch there is a very good chance, 2 out of 5 days, that the machine has rebooted. This also may happen during the day when I am actively working on the machine but that is pretty rare. The sleep cycle seems to be the main trigger.
This is an upper end machine with an SSD drive so the reboot does not take too long but it does interrupt my day and it may happen a couple of times a day, when I come in, after lunch and then maybe after a meeting. Yes, all the programs restart but they don't show up in the same position or with the same data showing. Sublime text appears on screen 1 instead of screen 2. Finder does not have the same tabs open. Chrome might be annoyed in some manner. I will not have the tabs in iTerm on the same directories.
This was never a problem in the past. The MacBook just worked. Now it reboots and has issues with DNS getting lost part way through the day as well. Ping will not find a machine but NSLookup will.
I also have a Dell PC that is used for my Windows activities running Windows 8.1. I leave Outlook, Hipchat, Sublime Text, Chrome and a few other things running on it as well. I do a lot of my graphics work on that machine because Paint.NET is free and pretty darn full featured. We also use TFS for version control and I do that work on that machine along with anything I need to do in Visual Studio including C#. I don't have a massive love for Windows but at least that machine is only rebooting when it needs to do updates, which does occur too often for an OS, but otherwise it is there ready to go.
iOS has become less stable as well. I think Apple needs to stagger the releases instead of trying to do MacOS, iOS and iOS hardware release all at the same time. I bet their QA department is hammered during that yearly cycle and it is really starting to show. I love new and exciting things but they need to be stable. Right now Yosemite is not stable and is highly annoying.
Showing posts with label Apple. Show all posts
Showing posts with label Apple. Show all posts
Tuesday, January 20, 2015
Tuesday, January 13, 2015
Why I have given up on Interface Builder and Story Boards
I just ran into another case where Interface Builder did not allow me to do what I wanted to do and I finally just gave up and pulled everything but the first view controller from the storyboard. This is the story of how I got to this point.
My first iOS app was one of "finish this". Another developer who was no longer with the company had developed the app. I had the job of finishing the app and converting it to Android. I already knew Java and had written an Android app that was in the store. The iOS version used NIBs as this was back in the iOS 4 timeframe.
I continued down the NIB path and converted the app to be universal with special code for iPad layouts. There was special cases for landscape vs. portrait on one of the screens as well. Seemed to work OK but it was a fairly straightforward app.
I worked only on Android apps for a some time before my next position where I did both iOS and Android work again.
The next iOS app I worked on was written by another developer and he used storyboards. Still using the old style layouts with pixel perfect positioning. I kept the storyboards in place seeing some of the advantages of using them and added the iPad storyboard side of things. I liked how much easier it was to get things going, used segues and like the idea of seeing the program flow in a visual designer. Took quite a bit of web research to understand how it all tied together and a lot of clicking on tabs in IB to find all the secret nooks and crannies where you could set things.
I did a couple of other apps for the company that I got to write from scratch. I used the new found storyboards for them as well. Sadly none of these apps went to market as they never finished the server side of the work. Lots of pretty apps to demo at sales meetings but they were just demos.
For my current job I am again getting to write the app from scratch. I am doing the same with the Android side of things. I started out using storyboards and it was time to get into autolayout. Since I have been doing Android work and I have also done a lot of Java desktop work I have a solid understanding of doing layouts that scale.
I dove into autolayout and found it rather confusing. It appears to me to be written in the land of academia instead of the land of real world programming. One layout to rule them all no matter how you have to force things into it. Very verbose in one code only format and very terse in the other. If you do it in Interface Builder then you just have to know how to do things. Click here, Ctrl + Click here, set up constraints, delete them, set them up again, have them conflict, pull hair. Always something wrong and it get really bad when you have a complex layout. For a company that prides itself in UI and UX I must say IB is not a good reflection of that goal.
After fighting it and working with other iOS devs over chat I found Masonry and switched to that. Yes, it is code and not WYSIWYG but I could create complex layouts and have them work. I could do different layouts for iPad and iPhone and follow them logically. I still have storyboard layouts but most of them were empty as the code created the real layout. I was just using them for segues and to see program flow. That was until yesterday.
There I was back in Interface Builder. I just wanted a UITableView to move down one level, to have another UIView as its parent. IB fought me tooth and nail. I could and a UIView to the list but it would not show up under the UIViewController no matter how I dragged and dropped and clicked. I then said screw it and deleted that entire view controller and created a new one where I could re-add the UITableView but then all my segue links broke and all the IBOutlets into the code broke and I would have to do it again for the iPad storyboard and all the work went on and on. Plus Xcode crashed more than once while I was in it doing simple things.
Storyboards end up sucking pretty quickly. There is not enough screen room to see your iPad layouts. You get to see one scene at a time. Sure you can zoom out but the minute you edit something it zooms back in. Just opening a storyboard seems to trigger Xcode into thinking there was a change. If you look in the XML you will see it changed x = 4.0 to x = 3.999999999 or something just as stupid. Everything I did I had to do twice, once for iPhone and once for iPad. The IDE does not tell you if you forget to wire up a UIView to an IBOutlet. Objective C does not care if you send messages to a nil object. Moving a UIView can screw up the whole layout quickly. You can't see all the constraints in one place, you have to look in each level of the layout to see them and they are terse and unrelated to each other. When you try to Ctrl+Drag a UIView into the code you hardly can see anything else on screen.
I gave up. IB was fighting me not helping me. I converted all the code to Masonry and I was able to control that layout exactly. I had to move all the segue processing in code as well. It took me all day to get my code back to where it was before but now I am in control of all of it.
I don't have to do things twice. iPad and iPhone both work from one code base. I may have some if statements in code to tweak layout for iPad but I don't have to double layout it out in a crappy UI editor called IB and I don't have to double connect every UIView to a IBOutlet.
I can move a control around in my layout by changing a few lines of code instead clicking a bunch of times in IB and having it get pissed and redo other constraints.
I can name my controls so when I do get log messages about my layout being screwy I know exactly which UILabel it is mad about instead of guessing.
Another issue that bit me, I fixed, that bit me again and I fixed the right way arose. I needed a second line for the title area on iPhone. iPad has enough horizontal space to not need this. I was using the navigation prompt property which adds a second line of text to the title area. On Android I could use title / subtitle to do same thing but on Android this requires no extra vertical space.
How did this bite me twice? A number of months ago I wanted to add a UILabel above my UITableView but I could not due to same issues that I just covered, I could not get the UITableView hosted by another UIView. Thus I used the prompt property. It worked OK. After the conversion away from storyboards everything in this UIViewController aligned just fine the first time I displayed it but when I tapped a table row and moved to the detail screen then back to the table screen setting the prompt caused the navigation area to grow and it covered up part of my table. Rotating to landscape and back would fix it. I tried all sorts of relayout, needs display, calculation of offsets etc. and could not get it to work. Why autolayout would not stay in sync is beyond me but I got sick of fighting that.
Then I remembered what I originally wanted to do - put a UILabel above the UITableView on iPhone only. Now I am in control as I am using Masonry. Put the UILabel in place and changed all code references from prompt = to promptLabel.text = and I have a working layout the way I originally wanted.
I have no plans use prompt again due to it screwing up layouts and I will not be using storyboards or Interface Builder either. They just are not stable and cause more trouble than they are worth. I also do most of my work in AppCode instead of Xcode as AppCode does a much better job in a lot of areas. Better editor, much better refactoring, GIT actually works properly and it is stable. I have had it crash on me once in the two plus years I have been using it.
The other added benefit - I can take my code and drop it in another project and it will work. I have no dependencies on copying the layouts twice and having to manually reconnect every single freaking UIView to an IBOutlet. My code is self contained. It lays itself out and knows how to talk to all of its controls.
Goodbye IB and storyboards. I don't miss you.
My first iOS app was one of "finish this". Another developer who was no longer with the company had developed the app. I had the job of finishing the app and converting it to Android. I already knew Java and had written an Android app that was in the store. The iOS version used NIBs as this was back in the iOS 4 timeframe.
I continued down the NIB path and converted the app to be universal with special code for iPad layouts. There was special cases for landscape vs. portrait on one of the screens as well. Seemed to work OK but it was a fairly straightforward app.
I worked only on Android apps for a some time before my next position where I did both iOS and Android work again.
The next iOS app I worked on was written by another developer and he used storyboards. Still using the old style layouts with pixel perfect positioning. I kept the storyboards in place seeing some of the advantages of using them and added the iPad storyboard side of things. I liked how much easier it was to get things going, used segues and like the idea of seeing the program flow in a visual designer. Took quite a bit of web research to understand how it all tied together and a lot of clicking on tabs in IB to find all the secret nooks and crannies where you could set things.
I did a couple of other apps for the company that I got to write from scratch. I used the new found storyboards for them as well. Sadly none of these apps went to market as they never finished the server side of the work. Lots of pretty apps to demo at sales meetings but they were just demos.
For my current job I am again getting to write the app from scratch. I am doing the same with the Android side of things. I started out using storyboards and it was time to get into autolayout. Since I have been doing Android work and I have also done a lot of Java desktop work I have a solid understanding of doing layouts that scale.
I dove into autolayout and found it rather confusing. It appears to me to be written in the land of academia instead of the land of real world programming. One layout to rule them all no matter how you have to force things into it. Very verbose in one code only format and very terse in the other. If you do it in Interface Builder then you just have to know how to do things. Click here, Ctrl + Click here, set up constraints, delete them, set them up again, have them conflict, pull hair. Always something wrong and it get really bad when you have a complex layout. For a company that prides itself in UI and UX I must say IB is not a good reflection of that goal.
After fighting it and working with other iOS devs over chat I found Masonry and switched to that. Yes, it is code and not WYSIWYG but I could create complex layouts and have them work. I could do different layouts for iPad and iPhone and follow them logically. I still have storyboard layouts but most of them were empty as the code created the real layout. I was just using them for segues and to see program flow. That was until yesterday.
There I was back in Interface Builder. I just wanted a UITableView to move down one level, to have another UIView as its parent. IB fought me tooth and nail. I could and a UIView to the list but it would not show up under the UIViewController no matter how I dragged and dropped and clicked. I then said screw it and deleted that entire view controller and created a new one where I could re-add the UITableView but then all my segue links broke and all the IBOutlets into the code broke and I would have to do it again for the iPad storyboard and all the work went on and on. Plus Xcode crashed more than once while I was in it doing simple things.
Storyboards end up sucking pretty quickly. There is not enough screen room to see your iPad layouts. You get to see one scene at a time. Sure you can zoom out but the minute you edit something it zooms back in. Just opening a storyboard seems to trigger Xcode into thinking there was a change. If you look in the XML you will see it changed x = 4.0 to x = 3.999999999 or something just as stupid. Everything I did I had to do twice, once for iPhone and once for iPad. The IDE does not tell you if you forget to wire up a UIView to an IBOutlet. Objective C does not care if you send messages to a nil object. Moving a UIView can screw up the whole layout quickly. You can't see all the constraints in one place, you have to look in each level of the layout to see them and they are terse and unrelated to each other. When you try to Ctrl+Drag a UIView into the code you hardly can see anything else on screen.
I gave up. IB was fighting me not helping me. I converted all the code to Masonry and I was able to control that layout exactly. I had to move all the segue processing in code as well. It took me all day to get my code back to where it was before but now I am in control of all of it.
I don't have to do things twice. iPad and iPhone both work from one code base. I may have some if statements in code to tweak layout for iPad but I don't have to double layout it out in a crappy UI editor called IB and I don't have to double connect every UIView to a IBOutlet.
I can move a control around in my layout by changing a few lines of code instead clicking a bunch of times in IB and having it get pissed and redo other constraints.
I can name my controls so when I do get log messages about my layout being screwy I know exactly which UILabel it is mad about instead of guessing.
Another issue that bit me, I fixed, that bit me again and I fixed the right way arose. I needed a second line for the title area on iPhone. iPad has enough horizontal space to not need this. I was using the navigation prompt property which adds a second line of text to the title area. On Android I could use title / subtitle to do same thing but on Android this requires no extra vertical space.
How did this bite me twice? A number of months ago I wanted to add a UILabel above my UITableView but I could not due to same issues that I just covered, I could not get the UITableView hosted by another UIView. Thus I used the prompt property. It worked OK. After the conversion away from storyboards everything in this UIViewController aligned just fine the first time I displayed it but when I tapped a table row and moved to the detail screen then back to the table screen setting the prompt caused the navigation area to grow and it covered up part of my table. Rotating to landscape and back would fix it. I tried all sorts of relayout, needs display, calculation of offsets etc. and could not get it to work. Why autolayout would not stay in sync is beyond me but I got sick of fighting that.
Then I remembered what I originally wanted to do - put a UILabel above the UITableView on iPhone only. Now I am in control as I am using Masonry. Put the UILabel in place and changed all code references from prompt = to promptLabel.text = and I have a working layout the way I originally wanted.
I have no plans use prompt again due to it screwing up layouts and I will not be using storyboards or Interface Builder either. They just are not stable and cause more trouble than they are worth. I also do most of my work in AppCode instead of Xcode as AppCode does a much better job in a lot of areas. Better editor, much better refactoring, GIT actually works properly and it is stable. I have had it crash on me once in the two plus years I have been using it.
The other added benefit - I can take my code and drop it in another project and it will work. I have no dependencies on copying the layouts twice and having to manually reconnect every single freaking UIView to an IBOutlet. My code is self contained. It lays itself out and knows how to talk to all of its controls.
Goodbye IB and storyboards. I don't miss you.
Tuesday, July 24, 2012
Today's Apple Fun!
I need to test a new app on the iPad. iPad is 5.1x but I was on Snow Leopard and using Xcode 4.2. Can't run the iOS 5.1x SDK on this platform. I got Lion ready to go finally. Had to buy a new larger USB key so I picked up a $9 16GB at Microcenter over lunch.
Run disk tools to create Lion installer on USB key
Lion install went smoothly.
Run Xcode, tells me it is too old. Drag it to trash and it crashes.
Install updates to Lion amounting to 1.84g of download and install.
Still wants to install iTunes update but it fails on two attempts - give up on that.
Try to install free application from App Store - Xcode for Lion.
Wants credit card information, nope, not on a shared work laptop.
Look on web and find you can set up your account under iCloud without credit card info.
Attempt to do that but it wants to verify email first.
Don't appear to be getting email to confirm.
Finally realize it came to my personal account, I have gone round and round with Apple over this and they can't fix it - I log in with my work email but can't associate my work email account to the Apple account.
Confirm iCloud email via link click and login on my PC to Apple website
Ask iCloud to try again but it fails.
Close iCloud.
Open iCloud
iCloud is now happy so I click into manage account and it has a NONE option for credit card.
Update and save info.
Get multiple Apple emails to my personal email about the updates.
Open App Store.
Click on Free on Xcode in search results
Click on Install
Nothing happens
Click on Xcode to move from search results to full screen Xcode information
Click on Install
States Installing... but no status visible
Click on Purchases so I can monitor 1.53 download
Get another email from Apple saying I am downloading stuff and if I did not do that I should change my password.
Ignore the email.
Run Xcode
Asks to uninstall old Xcode (guess the crash really did fail even though Xcode did not appear any longer in Applications)
Install old Xcode
Xcode runs some extra updates
Xcode up and running and I am able to run the App on my test iPad.
App runs great, scrolls around at full speed.
Try a couple of times to update iTunes and it continues to fail
Search on Google and it is suggested I download the DMG directly from Apple iTunes site
Download 170 meg of iTunes fun
Start installer - asks to close Xcode
Close Xcode - run installer
Installs just fine this time
Run Update checker - no updates found
System is now up to date, well as up to date as it can be with Mountain Lion ready in a few hours, Xcode runs and I can go back to app development. It was a bit of a winding road to get it all to happen though. Felt like way too many hoops to jump through to install the few things I needed to keep working.
UPDATE
Java is not installed by default with Lion. I am now downloading and installing Java so I can use AppCode and IntelliJ to do development. The keystrokes in Xcode are driving me nuts so I am going to switch to AppCode to see how that goes.
Asks to uninstall old Xcode (guess the crash really did fail even though Xcode did not appear any longer in Applications)
Install old Xcode
Xcode runs some extra updates
Xcode up and running and I am able to run the App on my test iPad.
App runs great, scrolls around at full speed.
Try a couple of times to update iTunes and it continues to fail
Search on Google and it is suggested I download the DMG directly from Apple iTunes site
Download 170 meg of iTunes fun
Start installer - asks to close Xcode
Close Xcode - run installer
Installs just fine this time
Run Update checker - no updates found
System is now up to date, well as up to date as it can be with Mountain Lion ready in a few hours, Xcode runs and I can go back to app development. It was a bit of a winding road to get it all to happen though. Felt like way too many hoops to jump through to install the few things I needed to keep working.
UPDATE
Java is not installed by default with Lion. I am now downloading and installing Java so I can use AppCode and IntelliJ to do development. The keystrokes in Xcode are driving me nuts so I am going to switch to AppCode to see how that goes.
Thursday, January 26, 2012
App released for App Store
It took 13 days to get the app released to that Apple App Store this time. I sent them a note yesterday as I was worried about the "review requires additional time" status. From what I could tell on the web this can be a death knell. It appears to mean Apple does not like something and wants to really review it to see if you are breaking any rules.
I sent them a note explaining we just send the data back to our server for it to be processed by the back office staff. Everything is pretty darn tame. I research everything to make sure I am not using a private API, all the graphics are legal, tool bars are in the correct place, back button works like it should, etc. We do store a lot of data on the phone due to CPT, ASA and Diagnosis codes for quick look up later. I wrote my own pop-up menu system that works on both iPhone and iPad to mimic the one I use on the Android but that is just a custom control. I explained all that in my note and it appears to have worked.
I have a couple of guesses. One they might have accidentally put it in the wrong status. I am sure this is easy enough to do especially if you are just choosing from a combobox. Second they could have been worried we were making money with the app by sending claims directly to insurance and they wanted a 30% cut of that. This app is just a simple tool to get data to the back office for processing. It saves the anesthesiologist time and money by not needing to drive back to the office to drop off paperwork.
In the end it is released and ready for our clients. We will be calling them today just in case they don't notice an update is available via the OTA process. I hope to hear some good news from them as I believe I have fixed all known issues at this time.
Previously it was released in a more timely manner: 5 days, 2 days, 2 days and 13 days for this round. Being in release limbo sucks.
Monday, January 23, 2012
Why you don't get crash reports from Apple
I thought our little app was doing great, never a single crash report but then clients said they are crashing it. So what is the deal? Turns out to get a crash report the end user MUST connect their phone to iTunes and OK the submission of crash reports. Our clients are Doctors, they never connect their phone. They use it for scheduling etc. as a smart phone. We will never see a crash report from them.
I looked in the logs and I see they are running iOS 4.1. Yep pretty old but since Apple did not support OTA (over the air just in case you don't know) OS updates they never update their phone. Now 5.0x is not all that great on old phones, they run pretty slow with it, but since many users never attach their phone they never even see good updates and patches. Face it, iOS is fragmented but in a different way than Android.
On the Android side we see crash reports. When the app dies you are given the choice to send the report over your 3G / Wifi / whatever data connection. Our app is based on being connected so sending this data is no big deal. Apple decided to bundle up all the crashes on the phone and horde them like a dragon.
When I attach an internal beta testers phone to my Mac I get to see all the crashes from our app and all other apps on the device. Stuff crashes a lot from what I see. Those developers never get to see their crashes either. This is a damn shame and a total false sense of security. I pretty much wanted to scream at how annoyed I am at Apple for not giving me access to crash reports so I can make my app better.
I am now going to have to look into some user written crash handlers. You can catch exceptions at a higher level and then you need to try and save the crash somewhere then write it to your server during the next log in. When your app is crashed you can't do much with the data and since there is no central support you are on your own as to how to handle it. We will need a new API on our server to accept the crash data so I can log in and get it at a later time to analyze the situation. They need to fix this. Apple has been less than developer friendly through this whole process and they continue to piss me off.
On the Android side my Motorola Xoom updated to Ice Cream Sandwich and I am happy with the upgrade. The fonts look a lot nicer and I like the new back / home / menu button look. I don't care for the "clear all" vs. "clear individual" notifications from the status bar.
I wish my phone could be upgraded but they stopped that at Froyo. This is a big downside on the Android side. Each manufacturer gets to decide how much they want to hose over the phone so it is unique to them but when they do that they can skip all future Android releases. As a developer I want the latest stuff. End users don't seem to care and just want it to run. See the iOS stuff above to find out the a lot of iOS users never upgrade. With OTA maybe that will change on the iOS side but the 4.x to 5.x upgrade was not friendly to me or others causing you to lose everything if you did not back it up first. Doing that OTA is not a good idea.
I understand not getting ICS on my phone but I really want Gingerbread as Google sped up various aspects of the UI with some new memory management etc. Guess I will look into rooting it at some point in the future and if it works for me I will do it on my wife's phone too.
Friday, January 20, 2012
Ouch - App Store rejection!
After a full week of waiting to review our app got rejected by the Apple app store. They found a crash, a legitimate and easy to reproduce crash that should have never made it past me or QA. A crash that occurred in all previous versions of the software. A crash that made it through to the store multiple times.
It involved turning off some of the editable sections via the admin tool. I was using a tag as an array offset, if all sections are enabled the tag would equal the offset, but in the one test case this was going to cause an index out of bounds. I screwed up and should have labeled the variable as tag instead of as section. I probably was going to do that at one point but the crappy refactoring support in Xcode means I skip doing work like that from time to time.
It is my fault for not catching this earlier. For the test log in we sent to Apple you had three practices to choose from. The bug only occurred on the third practice in the list and only when you pressed the (+) to add a new image to list. Very glad Apple found this issue. I did not want a crash out in the hands of our users and I am sure many would have run into this issue as the layout of the editable items is totally configuration via our administration tool. That tool is not a mobile app but how each client configures what they want the doctor to enter is totally up to them. Annoying this was not caught by QA. As a developer you don't have time to configure piles of test cases in the admin tool then test things out on the mobile side of things. Something like this I should have tested though as it is pretty easy to configure and verify.
It works just fine on the Android. Due to language and GUI component differences the code is not a direct port between the platforms. Could be I was doing a quick conversion to the iPhone or I did the iPhone side first and caught the issue during the Android conversion or the Android code is so different that bug would not occur or I forget to go fix it under iOS post Android conversion. I was back and forth between the two on a daily basis.
Being the sole developer for two platforms is just not easy. I have no one here that can do Objective C code reviews. Someone could look over the Android Java code but I am the only Android developer so some parts of the API would not be familiar too them. Java tends to be Java so I am sure they could find issues if they looked hard enough. Heck, I could find issues if I gave it all a once over. I fixed the issue, ran some tests and we submitted it again.
Within an hour it was back in "In Review" status so Apple obviously saw we got right on the fix and did not move us back to the end of the line. I really did not want our clients to wait another full week for Apple to just start looking at the app again. I am hopeful it gets through the review process in a few hours and we can contact clients starting Monday to let them know a new version is ready that fixes the camera issues and this new issue.
I just got another note from Apple that they need additional review time but they will keep me posted. Must be time for a real test instead of the past two times where it was just shuffled right out into production.
We don't appear to be getting crash reports from Apple. When we look in the crash report section nothing is listed even though clients reported crashes. I wonder if it is due to them running 4.1 iOS and the tabs for the crash reports start with the 4.2.x series. Does Apple throw away older iOS reports? We could tell clients to upgrade but we list support as 4.0x and above. Plus upgrading to 5.x series is not for the faint of heart. You darn well better back up everything because I know multiple people that had everything blown away. That was not the case when doing 4.0.x -> 4.1.x -> 4.2.x upgrades and people got a false sense of security. A lot of doctors just get the device and never connect it to a computer. I really don't want to walk them through that process.
Here's hoping the new update is available at the store on Monday!
It is my fault for not catching this earlier. For the test log in we sent to Apple you had three practices to choose from. The bug only occurred on the third practice in the list and only when you pressed the (+) to add a new image to list. Very glad Apple found this issue. I did not want a crash out in the hands of our users and I am sure many would have run into this issue as the layout of the editable items is totally configuration via our administration tool. That tool is not a mobile app but how each client configures what they want the doctor to enter is totally up to them. Annoying this was not caught by QA. As a developer you don't have time to configure piles of test cases in the admin tool then test things out on the mobile side of things. Something like this I should have tested though as it is pretty easy to configure and verify.
It works just fine on the Android. Due to language and GUI component differences the code is not a direct port between the platforms. Could be I was doing a quick conversion to the iPhone or I did the iPhone side first and caught the issue during the Android conversion or the Android code is so different that bug would not occur or I forget to go fix it under iOS post Android conversion. I was back and forth between the two on a daily basis.
Being the sole developer for two platforms is just not easy. I have no one here that can do Objective C code reviews. Someone could look over the Android Java code but I am the only Android developer so some parts of the API would not be familiar too them. Java tends to be Java so I am sure they could find issues if they looked hard enough. Heck, I could find issues if I gave it all a once over. I fixed the issue, ran some tests and we submitted it again.
Within an hour it was back in "In Review" status so Apple obviously saw we got right on the fix and did not move us back to the end of the line. I really did not want our clients to wait another full week for Apple to just start looking at the app again. I am hopeful it gets through the review process in a few hours and we can contact clients starting Monday to let them know a new version is ready that fixes the camera issues and this new issue.
I just got another note from Apple that they need additional review time but they will keep me posted. Must be time for a real test instead of the past two times where it was just shuffled right out into production.
We don't appear to be getting crash reports from Apple. When we look in the crash report section nothing is listed even though clients reported crashes. I wonder if it is due to them running 4.1 iOS and the tabs for the crash reports start with the 4.2.x series. Does Apple throw away older iOS reports? We could tell clients to upgrade but we list support as 4.0x and above. Plus upgrading to 5.x series is not for the faint of heart. You darn well better back up everything because I know multiple people that had everything blown away. That was not the case when doing 4.0.x -> 4.1.x -> 4.2.x upgrades and people got a false sense of security. A lot of doctors just get the device and never connect it to a computer. I really don't want to walk them through that process.
Here's hoping the new update is available at the store on Monday!
Monday, December 19, 2011
New application version out on both Markets on to MigCalendar
I finished up the latest release for both Android and iOS and QA accepted it as ready to release on Friday. I submitted it to the Android Market where it appeared nearly instantly. To my surprise it appeared in the Apple App Store on Sunday - I got an email from Apple on its updated status. I did not think they actually worked over the weekend. This is the second time it appeared two calendar days after submission.
Based on activity they just gave it the illegal method check once over and let it go to the store as it is an update to an existing application that requires a login to use. It is only useful to our clients. It is not like we are selling it and forcing you to buy a login outside of the App Store so I don't think Apple gives a rip about what it does, if it leaks memory or how clients use it. I don't they even care if it follows their UI guidelines. As far as I know it is not doing anything out of the norm. I triple make sure I am not using any private API calls, run it through the leak detector as I add features and really the app is used to access our servers and get to the data the client owns and to send updates to the data as needed. I am very happy it went through the process quickly.
Now that everything is out of beta we can turn on access at our server level and let the doctors have some real fun with the application. I am really curious to see how many installs we have for each platform and how much data traffic it generates. Doctors can take pictures of the medical paperwork on site so we should start to see images flying about soon enough. Well I won't see the images, I don't look at live medical records, but I can see file sizes and what not from the log files.
We will await feedback from the clients before we plan the next release. I have some items I would love to add to the program but if no user requests them it is better to work on the real needs and not my guesses. This means I am on break from the mobile side of things for a bit. Good thing to happen just before the holiday season.
I will be working on our front office appointment scheduling program. It makes heavy use of MigCalendar. I have messed around with that a bit but am a total novice. The original developer is not here so I will have to figure out most of it on my own. MigCalendar is a bit of an odd bird. Things are stored in statics that I don't feel belong there. The API is very powerful but not easy to understand. I started work on this a few months back and made a lot of notes so I am reviewing those and diving into the code. Various object constructors have numerous parameters which can get hard to follow.
Our current UI is lacking in usability. There is a tabbed interface but the tabs are really just controlling what is visible in the calendar. There are two buttons inside each tab that control the filtering operations. I am converting these into a combobox with 4 items mirroring the tab / button combinations listed above. This gives more vertical room in the UI and gets rid of a tab that is not really a tab and buttons that toggle but don't. It allows me to add more root + filter modes in the future and cleans up the code nomenclature as the buttons were namee after their functionality in the first tab which has no relationship to what they do in the second tab. It also leaves one instance of MigCalendar running instead of two. Yes, this whole application was in dire need of help.
Can't say I am looking forward to getting this all up and running again. One of those projects you just want to scrape and start from scratch. I feel like it should appear on "Extreme Code Makeover" and we should blow up a computer with C4 while some dude with OCD runs around screaming. Once I get over the initial learning curve it should not be too bad. Of course once it starts working like it should more requests will come in and I will be tagged as "the guy" that knows the appointment stuff. Since I am taking off the last week of the year I also get a chance to forget most of what I figure out this week. Nothing like starting over twice in a few weeks period.
Based on activity they just gave it the illegal method check once over and let it go to the store as it is an update to an existing application that requires a login to use. It is only useful to our clients. It is not like we are selling it and forcing you to buy a login outside of the App Store so I don't think Apple gives a rip about what it does, if it leaks memory or how clients use it. I don't they even care if it follows their UI guidelines. As far as I know it is not doing anything out of the norm. I triple make sure I am not using any private API calls, run it through the leak detector as I add features and really the app is used to access our servers and get to the data the client owns and to send updates to the data as needed. I am very happy it went through the process quickly.
Now that everything is out of beta we can turn on access at our server level and let the doctors have some real fun with the application. I am really curious to see how many installs we have for each platform and how much data traffic it generates. Doctors can take pictures of the medical paperwork on site so we should start to see images flying about soon enough. Well I won't see the images, I don't look at live medical records, but I can see file sizes and what not from the log files.
We will await feedback from the clients before we plan the next release. I have some items I would love to add to the program but if no user requests them it is better to work on the real needs and not my guesses. This means I am on break from the mobile side of things for a bit. Good thing to happen just before the holiday season.
I will be working on our front office appointment scheduling program. It makes heavy use of MigCalendar. I have messed around with that a bit but am a total novice. The original developer is not here so I will have to figure out most of it on my own. MigCalendar is a bit of an odd bird. Things are stored in statics that I don't feel belong there. The API is very powerful but not easy to understand. I started work on this a few months back and made a lot of notes so I am reviewing those and diving into the code. Various object constructors have numerous parameters which can get hard to follow.
Our current UI is lacking in usability. There is a tabbed interface but the tabs are really just controlling what is visible in the calendar. There are two buttons inside each tab that control the filtering operations. I am converting these into a combobox with 4 items mirroring the tab / button combinations listed above. This gives more vertical room in the UI and gets rid of a tab that is not really a tab and buttons that toggle but don't. It allows me to add more root + filter modes in the future and cleans up the code nomenclature as the buttons were namee after their functionality in the first tab which has no relationship to what they do in the second tab. It also leaves one instance of MigCalendar running instead of two. Yes, this whole application was in dire need of help.
Can't say I am looking forward to getting this all up and running again. One of those projects you just want to scrape and start from scratch. I feel like it should appear on "Extreme Code Makeover" and we should blow up a computer with C4 while some dude with OCD runs around screaming. Once I get over the initial learning curve it should not be too bad. Of course once it starts working like it should more requests will come in and I will be tagged as "the guy" that knows the appointment stuff. Since I am taking off the last week of the year I also get a chance to forget most of what I figure out this week. Nothing like starting over twice in a few weeks period.
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.
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.
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.
Subscribe to:
Posts (Atom)