Due to the new scheduler we needed to upgrade to the latest version of JIDE. First off JIDE has been a solid set of controls for our application but we don't upgrade very often so this was a multiple version number jump. JIDE is also very responsive to email requests and have fixed various issues we found in a timely manner. I highly recommend them if you need flexible grids, combobox tables, tree tables, etc.
During our upgrade we needed to toss out some code we used to override things JIDE did not do in the past and we also decided to allow the user to set the overall application font. Doing so brought up various cheats in our code. We had some of our controls return hard coded preferred dimensions. Now they use the current font to calculate their size. Some controls did not provide a preferred size. We use MigLayout pretty much everywhere so we had some hard coded "w 150!, h 22!" style parameters in the code which we removed.
We need to convert everything to MigLayout. I did a lot of the conversion from NetBeans FORM layout to MigLayout last year. Some of the panels used odd control overlaying - not card layout - so I left them alone. We know how to convert those and in fact have decided that overlay is really not the best way to handle the layout needs so we are replacing it anyway. Everyone will be happy to see all the forms gone. Removing the hard coding of sizes has caused us to clean up some of the MigLayout parameters too. Using size groups for buttons can keep things in a nice grid style layout along with better grow parameters have been a big help.
As far as preferred sizing goes the Mac needs slightly different sizes than the PC so we have some isMac() calls in the code to handle that. Under Win7 on the PC the drop down arrow to the right of a combobox sizes to match the overall combobox font, on the Mac it does not, that arrow is an image and sticks to one size.
We really should go through all the code and tag the buttons as OK, Cancel etc. so they show up in the right order on a Mac. Should have been done from the start and we are unsure if it would throw off our current Mac users to swap it at this point.
Our applications are used by medical staff to enter anesthesiology billing information. There are piles and piles of entry screens we are dealing with. The conversion has been handled by me and my boss over the past 10 days are we are nearing the finish. The ability to pick a larger font has been on our feature least for some time. A lot of the folks entering the data are 40+ years of age and they really want to have larger fonts. It will also help with demoing the product in a booth on a large monitor.
QA is going to have fun. They need to revisit every entry screen 4 times, PC large / small font then Mac large / small font. We have a FEST test script set up to bring up each screen and take a screen shot to assist in this area but you also need to verify TAB order and other oddness on the screen too. Now that JIDE has switched to using JComboBox etc. as their base classes for their controls it will be much easier to write FEST scripts for testing.
I have been doing all the Mac testing and tweaking up to this point. We don't want QA to start reporting things until we have given it a solid once over otherwise we will have a massive pile of issues of the type "we have not touched that code yet darn it" variety. Generally things have gone smoothly between the Mac and the PC. I do have one crash left on the Mac that does not occur on the PC. I am guessing this is related to something happening off the EDT that annoys the Mac. It is crashing way down in the Aqua Look and Feel.
I will probably move off of the conversion by the end of the day and move back on to the scheduler. All of this needed to be in place so I could have the new JAR files ready for me so it was a good breaking point. The new JIDE will go out with the next release but we don't know if the new scheduler will. I would rather have them go out in stages as both pieces will be a load for QA to digest.
Friday, February 24, 2012
Friday, February 10, 2012
Java needs a toDebugString to go with toString
toString() is a very handy Java method. It allows you and the debugger to display the value of an object in a nice format. The problem is toString() is not just used by the debugger and by your code for logging. This method is used by ListBoxes, Trees, ComboBoxes and other UI elements.
It would be great to add a second method toDebugString() that returns the string to be used by the debugger when inspecting objects and potentially for your logging leaving toString() for UI elements use. In the base Object toDebugString() would return toString() so unless you override toDebugString() they would both act identically. I have various objects that I want to use in a ListBox so I have to use toString() to return a very basic String for a variable usually called name or description. That is great for a ListBox but not for the debugger where I may want to know the name, colors, child count or any number of other things.
I just got done converting some handy debug toString() methods to the much simpler return name; variety in the scheduler code as I needed to show them in the UI. I just lost useful output in the debugger from this. I can easily do my own toDebugString() calls for logging and simple inspection but the Eclipse debugger will not call that when viewing then in a watch list.
Of course Eclipse helps in this area by allowing you to create Detail Formatters. Under Window -> Preferences -> Java -> Debug -> Detail Formatters you can define what you want displayed for various object types. It means you get to go through some extra hoops but you can see the results you want. I really would like to avoid the hoops and have a call right in the code for the object as it is easier to maintain than diving deep into an Eclipse dialog to set things. During initial development I tend to refactor my objects quite a bit.This is not portable to another IDE and if you keep a lot of projects open under a workspace this can get rather cluttered.
I am going to attempt to use the Eclipse Detail Formatters while testing / debugging this project to see how it goes. It could be my fears are unjustified but I really would love a simple / clean solution to this issue easily supported by all IDE / Debuggers.
It would be great to add a second method toDebugString() that returns the string to be used by the debugger when inspecting objects and potentially for your logging leaving toString() for UI elements use. In the base Object toDebugString() would return toString() so unless you override toDebugString() they would both act identically. I have various objects that I want to use in a ListBox so I have to use toString() to return a very basic String for a variable usually called name or description. That is great for a ListBox but not for the debugger where I may want to know the name, colors, child count or any number of other things.
I just got done converting some handy debug toString() methods to the much simpler return name; variety in the scheduler code as I needed to show them in the UI. I just lost useful output in the debugger from this. I can easily do my own toDebugString() calls for logging and simple inspection but the Eclipse debugger will not call that when viewing then in a watch list.
Of course Eclipse helps in this area by allowing you to create Detail Formatters. Under Window -> Preferences -> Java -> Debug -> Detail Formatters you can define what you want displayed for various object types. It means you get to go through some extra hoops but you can see the results you want. I really would like to avoid the hoops and have a call right in the code for the object as it is easier to maintain than diving deep into an Eclipse dialog to set things. During initial development I tend to refactor my objects quite a bit.This is not portable to another IDE and if you keep a lot of projects open under a workspace this can get rather cluttered.
I am going to attempt to use the Eclipse Detail Formatters while testing / debugging this project to see how it goes. It could be my fears are unjustified but I really would love a simple / clean solution to this issue easily supported by all IDE / Debuggers.
Wednesday, February 1, 2012
Some days you just rewrite what you did the previous day
Today was one of those days. I thought I came up with a really cool solution to block times and appointments sharing a cell span for the new appointment scheduler using JIDE. I had it all implemented yesterday and it appeared to be working nicely as I went home for the night and off to enjoy my son's band concert.
This morning I sat down and ran the program again just to see if I could get it to fail. Of course it did fail after a short time of testing. My fake data starts with one time block and two appointments with none of them overlapping. A time block is used to paint the background of the group of cells - say from 8 AM to noon - in a special hatched color pattern. This allows the provider to block a set of time for specific tasks such as OB or cancer only patients. You are allowed, encouraged actually, to schedule appointments in that time block. You can't move or resize the time block using the mouse, that is all done via a configuration dialog so you don't accidentally move it about during normal business activity. It needs to paint first and all appointments on top of it.
I had a bunch of code looking at each appointment as it was added to the schedule to see if the an existing cell span needed to be extended - either earlier start row or growing the row count. It worked most of the time unless I added appointments in a certain order and they overlapped but did not cause the cell span to grow. So the block was from 8 to noon and an appointment was from 9 to 10. It fits but I did not account for it thus I ended up adding two cell spans to JIDE table which annoys it when you try to delete them. I had added a cell span dump call to my table allowing me to see why the painting was all wacky. I tied the dump into an unused button on my test interface as I did not want the output filling up as I was dragging appointments around trying to get the problem to replicate. Once I really looked at the code I was not happy about adding a bunch more logic for special overlaps and cleaning up JIDE table Cell Spans and internal Cell Spans. Time to step back and take a new perspective.
What I decided to do is add the appointments as a collection. I can put each appointment in its column, then I can sort a column of appointments by row and row span. After sorting I can easily come up with unique cell spans. I add those spans to the JIDE grid then I also calculate which row / column to do the setValueAt call for adding appointments to a collection for that cell. You don't get paint calls for every cell in the table, only the one in the upper left corner of a cell span. I needed to consolidate all appointments for a span to that one callback spot. An earlier attempt at that had less than stellar results.
I ended up deleting a lot of code and making the logic a ton easier to debug and understand. Looking at the data to decide what to paint is also cleaner. Still runs slower on the Mac that I want so tuning will be in order but I want to get overlapped appointment painting to work first then I will tune things. I have a feeling it is JXLayer related on the Mac and I might not have much control over that. I have broken down and reconstructed the logic more than once already so no need to optimize yet.
Today's implementation appears to be pretty solid. I have been unable to get it to screw up after beating on it via lots of drag and drop and tossing numerous appointments at the grid. I even fixed a clipping issue that only occurred on the Mac. I am doing all my development on the PC but I copy the code over to the Mac as a backup being as I don't have a sandbox area in SVN to check anything in just yet. It is also good to run on more than one platform to catch any weird errors, graphical glitches or performance problems early in the process.
I have notes all over my whiteboard, scratch paper and in PSPad that I will go through so I can cross off the random thoughts that did not work. Next up is painting overlapping appointments by insetting them from the edge and tracking the mouse into them allowing you to change the Z order. Could get kind of hairy but I think the new way I am storing things is going to help. My plan today was to implement that once I felt the code was solid. Since the code was not solid I did not get around to it today. Guess that is why we have tomorrows.
Next scary piece will be implementing a pivot. Allowing time to run in the columns and column categories to run as the rows. I don't want an IF statement every other line so I might have an object ready for each layout type for processing rows vs. columns. I hate to duplicate code but if it becomes too messy it will be worth it. Double the testing for sure. Get that all in place and I get to do week and month views. Somewhere in there I will have to move this into our main application to replace the current MigLayout. It needs to be a fully working custom control before I do that so I can concentrate on the real appointment data at hand and not on fixing scrolling and painting bugs. Plus it will allow other developers here to help out with dialog boxes and all the other decorations needed by a scheduler.
This morning I sat down and ran the program again just to see if I could get it to fail. Of course it did fail after a short time of testing. My fake data starts with one time block and two appointments with none of them overlapping. A time block is used to paint the background of the group of cells - say from 8 AM to noon - in a special hatched color pattern. This allows the provider to block a set of time for specific tasks such as OB or cancer only patients. You are allowed, encouraged actually, to schedule appointments in that time block. You can't move or resize the time block using the mouse, that is all done via a configuration dialog so you don't accidentally move it about during normal business activity. It needs to paint first and all appointments on top of it.
I had a bunch of code looking at each appointment as it was added to the schedule to see if the an existing cell span needed to be extended - either earlier start row or growing the row count. It worked most of the time unless I added appointments in a certain order and they overlapped but did not cause the cell span to grow. So the block was from 8 to noon and an appointment was from 9 to 10. It fits but I did not account for it thus I ended up adding two cell spans to JIDE table which annoys it when you try to delete them. I had added a cell span dump call to my table allowing me to see why the painting was all wacky. I tied the dump into an unused button on my test interface as I did not want the output filling up as I was dragging appointments around trying to get the problem to replicate. Once I really looked at the code I was not happy about adding a bunch more logic for special overlaps and cleaning up JIDE table Cell Spans and internal Cell Spans. Time to step back and take a new perspective.
What I decided to do is add the appointments as a collection. I can put each appointment in its column, then I can sort a column of appointments by row and row span. After sorting I can easily come up with unique cell spans. I add those spans to the JIDE grid then I also calculate which row / column to do the setValueAt call for adding appointments to a collection for that cell. You don't get paint calls for every cell in the table, only the one in the upper left corner of a cell span. I needed to consolidate all appointments for a span to that one callback spot. An earlier attempt at that had less than stellar results.
I ended up deleting a lot of code and making the logic a ton easier to debug and understand. Looking at the data to decide what to paint is also cleaner. Still runs slower on the Mac that I want so tuning will be in order but I want to get overlapped appointment painting to work first then I will tune things. I have a feeling it is JXLayer related on the Mac and I might not have much control over that. I have broken down and reconstructed the logic more than once already so no need to optimize yet.
Today's implementation appears to be pretty solid. I have been unable to get it to screw up after beating on it via lots of drag and drop and tossing numerous appointments at the grid. I even fixed a clipping issue that only occurred on the Mac. I am doing all my development on the PC but I copy the code over to the Mac as a backup being as I don't have a sandbox area in SVN to check anything in just yet. It is also good to run on more than one platform to catch any weird errors, graphical glitches or performance problems early in the process.
I have notes all over my whiteboard, scratch paper and in PSPad that I will go through so I can cross off the random thoughts that did not work. Next up is painting overlapping appointments by insetting them from the edge and tracking the mouse into them allowing you to change the Z order. Could get kind of hairy but I think the new way I am storing things is going to help. My plan today was to implement that once I felt the code was solid. Since the code was not solid I did not get around to it today. Guess that is why we have tomorrows.
Next scary piece will be implementing a pivot. Allowing time to run in the columns and column categories to run as the rows. I don't want an IF statement every other line so I might have an object ready for each layout type for processing rows vs. columns. I hate to duplicate code but if it becomes too messy it will be worth it. Double the testing for sure. Get that all in place and I get to do week and month views. Somewhere in there I will have to move this into our main application to replace the current MigLayout. It needs to be a fully working custom control before I do that so I can concentrate on the real appointment data at hand and not on fixing scrolling and painting bugs. Plus it will allow other developers here to help out with dialog boxes and all the other decorations needed by a scheduler.
Monday, January 30, 2012
Upgrade Vista to Win7 takes 5 hours - why?
With various upgrades and new hardware in the house only one machine was left running Vista, my wife's Gateway laptop. It has a 1920x1200 screen that she runs at a different DPI to read it easier. Once you do that Chrome screws up and you can't use the upper right button to minimize, maximize or close it. Vista was also having some other issues and since it was the only copy running in the house I decided it was time for it to go.
I had a buddy with exact same hardware do the upgrade and it went smoothly for him. I had a Win7 Ultimate DVD from a MS one day conference so there was no cash outlay. Just to be safe I used my Win7 Ultimate 64bit DVD hoping the key from MS would work. The MS conference DVD just listed 32bit but this was running 64bit Vista and I sure as heck did not want to downgrade that.
Put in the DVD and started the upgrade process around 2 PM. It got down around 7 PM. Really? Why the heck did an upgrade take that long? I really have no idea. It had 6 steps to the process and various steps would get stuck at 20% or some other percentage for over 30 minutes. I just left it alone checking on it every so often and finally the percentage would move. I thought that would only happen during one of the steps but it happened over and over. Plenty of space on the HD and this is not a slow machine but it really drug out the process.
Once that was all done I had to grab some patches off the web and reinstall the video driver with a couple of reboots to make sure it was all happy. Running like a champ and she likes the enhancements offered by Win7. Chrome works, you can right click on task bar items such as Word to see and open recent files, task bar is cleaner, easy to move items between monitors, shake to minimize all others, etc. Plus it is much easier for me to do phone support if every computer in house on same OS. Only the file / print server is on XP. I feel no real need to upgrade that box right away although I do feel the printer / fax / scanner support under XP for the Canon printer we have is a big buggy.
If I would have known it was going to take that long I would have started it earlier in the day. I was worried the upgrade would screw up so I have been putting this off. With a friend pulling it off on same hardware I felt better but I was also using a MS key from a slightly different OS, 32 vs. 64 bit, but all accounts on web said this would work. I did not want to lose any of her existing programs - Quicken, MS Office 2010 and others as she uses it on a daily basis. Anytime you upgrade someone else you want it to go perfect otherwise you hear about it for days. Doing your own hardware is not so bad, you can put up with a lot, but dealing with others is a bear.
Feels good to have this off the books. Nice way to end the weekend and she is happy. I also took some weekend time to rip more of my CD collection to give me some variety of tunes at work. I listen to a lot of older music (80s, 90s) and I have it all on legal CDs that just sit in a cabinet. Good to be able to hear the old hair metal at work. Listening to "The Dark Saga" from Iced Earth right now. My son wanted to try some other songs out too and along the line we lost some stuff I ripped a number of years ago. He wanted Adam Ant back in his play list. I will have to listen to that today too. Good stuff.
I had a buddy with exact same hardware do the upgrade and it went smoothly for him. I had a Win7 Ultimate DVD from a MS one day conference so there was no cash outlay. Just to be safe I used my Win7 Ultimate 64bit DVD hoping the key from MS would work. The MS conference DVD just listed 32bit but this was running 64bit Vista and I sure as heck did not want to downgrade that.
Put in the DVD and started the upgrade process around 2 PM. It got down around 7 PM. Really? Why the heck did an upgrade take that long? I really have no idea. It had 6 steps to the process and various steps would get stuck at 20% or some other percentage for over 30 minutes. I just left it alone checking on it every so often and finally the percentage would move. I thought that would only happen during one of the steps but it happened over and over. Plenty of space on the HD and this is not a slow machine but it really drug out the process.
Once that was all done I had to grab some patches off the web and reinstall the video driver with a couple of reboots to make sure it was all happy. Running like a champ and she likes the enhancements offered by Win7. Chrome works, you can right click on task bar items such as Word to see and open recent files, task bar is cleaner, easy to move items between monitors, shake to minimize all others, etc. Plus it is much easier for me to do phone support if every computer in house on same OS. Only the file / print server is on XP. I feel no real need to upgrade that box right away although I do feel the printer / fax / scanner support under XP for the Canon printer we have is a big buggy.
If I would have known it was going to take that long I would have started it earlier in the day. I was worried the upgrade would screw up so I have been putting this off. With a friend pulling it off on same hardware I felt better but I was also using a MS key from a slightly different OS, 32 vs. 64 bit, but all accounts on web said this would work. I did not want to lose any of her existing programs - Quicken, MS Office 2010 and others as she uses it on a daily basis. Anytime you upgrade someone else you want it to go perfect otherwise you hear about it for days. Doing your own hardware is not so bad, you can put up with a lot, but dealing with others is a bear.
Feels good to have this off the books. Nice way to end the weekend and she is happy. I also took some weekend time to rip more of my CD collection to give me some variety of tunes at work. I listen to a lot of older music (80s, 90s) and I have it all on legal CDs that just sit in a cabinet. Good to be able to hear the old hair metal at work. Listening to "The Dark Saga" from Iced Earth right now. My son wanted to try some other songs out too and along the line we lost some stuff I ripped a number of years ago. He wanted Adam Ant back in his play list. I will have to listen to that today too. Good stuff.
Thursday, January 26, 2012
Bigger dual monitors = productivity gain
Pretty much any programming shop you know will have dual screen monitors for their developers. There are a bunch of posts and studies about the potential productivity gains. I have been running dual 20" monitors at various jobs for a number of years. I have a 21" monitor and a 17" at home.
Generally when gaming at home I don't use the second monitor but maybe I need to get some work done but I want to monitor a football game. I can leave it running via a web page on the second screen or I will have the browser there with Java Doc for my current coding project. They gave away some older 17" LCD monitors at work so I grabbed a couple of them a few months back. I hooked one up to my wife's laptop and she can't believe how usable it has become. She does a lot of Excel / Word / Browser work.
I gave one to each of my sons. The one in high school uses his to keep the homework assignment up while working in Word. Much easier to keep track of all the requirements for the paper when you don't have to toggle between windows.
My other son has his hooked up to his laptop in mirrored mode. This allows his tutor to monitor what he is doing without hovering over his shoulder. All of them getting plenty of use and in a variety of methods.
Great, you love dual monitors but what is the deal with bigger ones? Generally bigger is better, up to a point at least and that is also the case for monitors. Just going bigger without the up in resolution would not have mattered. We needed some monitors for our medical coding department. We figured we could give them our existing monitors and we could get the upgrade. Just like it works at home where my old machines filter down to family members when I upgrade.
None of us wanted to lose vertical resolution. We were running 1600x1200. If you go 23" you end up losing vertical as most are 1080 for that dimension. Once you get used to see X number of lines of code you don't want to give it up. Almost all monitors are widescreen now. The new ones are 1920x1200. Bonus extra width, same height in pixels. My boss is thinking of just using one as they are so wide. I am running dual and loving it. The extra width means I was willing to split PSPad and Chrome on one screen and Eclipse and Explorer++ and other apps on the other. I can still see the same amount to code but I don't have to toggle between windows.
I keep all my random thoughts on program ideas, to do list, etc. in various tabs of PSPad. I copy things from the web into there and into Eclipse all the time. Now I feel I have the screen space to keep everything on screen and open. That is a productivity gain.
The new monitors also have better color making my graphics artist work easier too. Newer tech, not the newest as these are still the value line Dell monitors but better than the old ones for sure.
If you develop and you don't have dual monitors you are really missing out. If you do have dual monitors and have been running 20" for a long time then at step up to 24" may well be worth your time.
Generally when gaming at home I don't use the second monitor but maybe I need to get some work done but I want to monitor a football game. I can leave it running via a web page on the second screen or I will have the browser there with Java Doc for my current coding project. They gave away some older 17" LCD monitors at work so I grabbed a couple of them a few months back. I hooked one up to my wife's laptop and she can't believe how usable it has become. She does a lot of Excel / Word / Browser work.
I gave one to each of my sons. The one in high school uses his to keep the homework assignment up while working in Word. Much easier to keep track of all the requirements for the paper when you don't have to toggle between windows.
My other son has his hooked up to his laptop in mirrored mode. This allows his tutor to monitor what he is doing without hovering over his shoulder. All of them getting plenty of use and in a variety of methods.
Great, you love dual monitors but what is the deal with bigger ones? Generally bigger is better, up to a point at least and that is also the case for monitors. Just going bigger without the up in resolution would not have mattered. We needed some monitors for our medical coding department. We figured we could give them our existing monitors and we could get the upgrade. Just like it works at home where my old machines filter down to family members when I upgrade.
None of us wanted to lose vertical resolution. We were running 1600x1200. If you go 23" you end up losing vertical as most are 1080 for that dimension. Once you get used to see X number of lines of code you don't want to give it up. Almost all monitors are widescreen now. The new ones are 1920x1200. Bonus extra width, same height in pixels. My boss is thinking of just using one as they are so wide. I am running dual and loving it. The extra width means I was willing to split PSPad and Chrome on one screen and Eclipse and Explorer++ and other apps on the other. I can still see the same amount to code but I don't have to toggle between windows.
I keep all my random thoughts on program ideas, to do list, etc. in various tabs of PSPad. I copy things from the web into there and into Eclipse all the time. Now I feel I have the screen space to keep everything on screen and open. That is a productivity gain.
The new monitors also have better color making my graphics artist work easier too. Newer tech, not the newest as these are still the value line Dell monitors but better than the old ones for sure.
If you develop and you don't have dual monitors you are really missing out. If you do have dual monitors and have been running 20" for a long time then at step up to 24" may well be worth your time.
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.
Subscribe to:
Posts (Atom)