We have a dashboard style web page used by our clients. I recently converted the charting side of that from flot to HighCharts. HighCharts gives much nicer looking charts by a long shot and the price was reasonable. All of that work was in JavaScript which I must say I don't miss and am very happy to get back into the mobile side of things.
JavaScript is just barely acceptable on an iPad or Android Tablet. Yes, I tweaked various UI aspects to make them more touch friendly but if we want to be able to look a client in the eye and tell them we have a dashboard that works on their tablet we need to go true native mobile.
All the code I have done in the past has been universal phone and tablet. For this type of dashboard we are going to start tablet only. We really want to design to use the space available. Of course 1024x768 (older iPad and iPad mini current maximum) is not a ton of space but it is what a number of folks run on even older desktop PCs if they only have a 15" LCD.
At this point I am sketching out ideas and have started a framework on the Android side. I am going to start there as this seems a perfect fit for fragments within an activity. Previously I have used fragments to learn about them and knowing it is the proper way to approach the future. Now I will get to exploit so much more of their power. I have not had the need to swap in one fragment for another or to add new ones to an activity, I have only defined them in the XML and let them operate as is.
Since this will target 3.0 and above on large devices I don't even have to worry about the compatibility library. Nice to get to be able to fully use the newer API features.
I am using achartengine for the pie, line and bar charts on the Android side and core-plot on the iOS side of things. The current smaller app just displays a pie chart so I will need to learn my way around the others.
Not sure what approach I will take on the iOS side of things. There is nothing like fragments there so I will get to deal with UI views and manual placement of things. This is why I plan to get it up and running on Android first so I can knock out the initial design without fighting layout issues. I should be able to figure out a number of UI patterns such tab controls, menu options, widget manipulation buttons etc. and run them by beta testers before I begin the iOS conversion.
Friday, September 27, 2013
Thursday, September 5, 2013
AAAARRGGGG iOS layouts stink!
I hate iOS layout management. Yes, everyone loved it when you knew the iPhone had this one resolution and you could perfectly layout everything. All phones were held in portrait only mode. Even the auto code generator blocked landscape by default. We knew what you had and how you would use it so just shut up. All Apple devs told Android devs they were hosed with their stupid layout managers without true WYSIWYG editing. Na-na-na-na-boo-boo.
This meant if you wanted to support landscape you added code to move things around and resize them during orientation changes. You could still use IB to see that pristine portrait view. Then came the iPad which was used in landscape a lot. Just do IB in that mode.
Well IB sucks. Adding storyboards just allowed it to suck in some new ways. Sure you can tie you portrait screens together and you can do separate iPad and iPhone screens but you have to manually tie all the controls back to your source code with crazy Ctrl + Click drag and drop if you can get the right source file to appear in a squished down window below the stupid layout that is way too damn big for iPad screens that wants to constantly scroll and resize every freaking time you click on it!
You are an idiot - use auto layout. If you don't then you are hosed. But Apple did not backport that, you had to wait until most users were on iOS 6. Google backports, Apple does not. Apple is a jerk in this area. iOS 6 seems like a safe enough target at this point.
Auto layout has a new set of issues. IB really blows here. It has to have everything in perfect order even though when you are creating the layout you can't get it in perfect order until the layout is fully loaded with all the controls. They IB rewrites the damn file over and over. You lose the battle every single time wasting a huge amount of effort.
So screw IB, it has been screwing you. Besides if you want a team working on things they can't all have the storyboard open because version controls DIFF is nearly impossible. It is a SNAFU. Time to write it all in code and skip everything related to IB.
You have a couple of choices. Use the auto layout weird ASCII stuff, which is just ugly to read, or use NSLayoutConstraints manually. I think I am going NSLayoutConstraints. If I am getting no WYSIWYG support I might as well take full controls. That ASCII stuff is too bizarre. Honestly this all feels like I am moving back into the land of GridBagLayout in Java.
GridBagLayout was the end all do all layout manager for Java back in the day. Yes, I did some crazy layouts with it that worked and even allowed you to resize the panel and flow properly. The code was ugly and not maintainable. You could not look at it and tell what the hell was going to display on screen and you could not add a new control between other controls without totally screwing everything up. I worked with developers that used GridBagLayout for everything even though a simpler BorderLayout would have worked. Use the right tool for the job people.
Look Apple there were a ton of other good examples of how to do things. MigLayout for example if you only want one layout manager. The Android XML way of doing things if you don't might multiple layout managers that deal with each other. At least with Android you can layout portrait and landscape and just put them in different directories. There is a WYSIWYG viewer too. I use it to preview the code changes I make in XML and so far have been able to build every layout I have wanted. The Android side is not perfect but is better than what I have seen from Apple.
Nope, Apple just puts all of that on you. Now I get to manually code all this crap and other devs will be able to see what it looks like when they run the code.
I just wanted to convert a current screen from a table view to a normal view. The original developer misused a table view for the screen and I need to clean it up and give a better look. IB does not like it when you try to change view types. Time to punt. Yes, I am using Xcode 5.x and I know it is supposed to have better auto layout support but it is still a mess.
Having spoken to my other iOS developer friends they have all stated it is time to move as far away from IB as possible. It has done nothing but screw them over. They think I am a fool for attempting to stick with IB as long as I have. I really just wanted to get the current project off the books but that is not going to happen. I can try and blow away the current table with a normal view then reattach the segues to the new view and leave it at that but that seems a new waste of effort.
I am going to have to learn auto layout. It is the new Apple way of doing things. It is the only hope if Apple decides to ever come out with a new resolution, which I really think they should. People are expecting HDTV on their devices. 1024x768 on the iPad mini is not cutting it anymore.
Maybe someone will come out with an excellent layout manager for iOS that will solve a number of these issues. At this time I don't care about WYSIWYG at the start. Something that is easy to code and maintain is what I want. I enjoyed working with MigLayout. I converted over 300 Java desktop screens from old NetBeans format to MigLayout at a previous company. I find the Android layout managers more difficult that MigLayout but still serviceable. The new Android Studio does a really nice job showing me a preview of my screens as I edit the XML. The layouts work and scale on various device sizes.
Done with my rant. Off to code NSLayoutConstraints.
This meant if you wanted to support landscape you added code to move things around and resize them during orientation changes. You could still use IB to see that pristine portrait view. Then came the iPad which was used in landscape a lot. Just do IB in that mode.
Well IB sucks. Adding storyboards just allowed it to suck in some new ways. Sure you can tie you portrait screens together and you can do separate iPad and iPhone screens but you have to manually tie all the controls back to your source code with crazy Ctrl + Click drag and drop if you can get the right source file to appear in a squished down window below the stupid layout that is way too damn big for iPad screens that wants to constantly scroll and resize every freaking time you click on it!
You are an idiot - use auto layout. If you don't then you are hosed. But Apple did not backport that, you had to wait until most users were on iOS 6. Google backports, Apple does not. Apple is a jerk in this area. iOS 6 seems like a safe enough target at this point.
Auto layout has a new set of issues. IB really blows here. It has to have everything in perfect order even though when you are creating the layout you can't get it in perfect order until the layout is fully loaded with all the controls. They IB rewrites the damn file over and over. You lose the battle every single time wasting a huge amount of effort.
So screw IB, it has been screwing you. Besides if you want a team working on things they can't all have the storyboard open because version controls DIFF is nearly impossible. It is a SNAFU. Time to write it all in code and skip everything related to IB.
You have a couple of choices. Use the auto layout weird ASCII stuff, which is just ugly to read, or use NSLayoutConstraints manually. I think I am going NSLayoutConstraints. If I am getting no WYSIWYG support I might as well take full controls. That ASCII stuff is too bizarre. Honestly this all feels like I am moving back into the land of GridBagLayout in Java.
GridBagLayout was the end all do all layout manager for Java back in the day. Yes, I did some crazy layouts with it that worked and even allowed you to resize the panel and flow properly. The code was ugly and not maintainable. You could not look at it and tell what the hell was going to display on screen and you could not add a new control between other controls without totally screwing everything up. I worked with developers that used GridBagLayout for everything even though a simpler BorderLayout would have worked. Use the right tool for the job people.
Look Apple there were a ton of other good examples of how to do things. MigLayout for example if you only want one layout manager. The Android XML way of doing things if you don't might multiple layout managers that deal with each other. At least with Android you can layout portrait and landscape and just put them in different directories. There is a WYSIWYG viewer too. I use it to preview the code changes I make in XML and so far have been able to build every layout I have wanted. The Android side is not perfect but is better than what I have seen from Apple.
Nope, Apple just puts all of that on you. Now I get to manually code all this crap and other devs will be able to see what it looks like when they run the code.
I just wanted to convert a current screen from a table view to a normal view. The original developer misused a table view for the screen and I need to clean it up and give a better look. IB does not like it when you try to change view types. Time to punt. Yes, I am using Xcode 5.x and I know it is supposed to have better auto layout support but it is still a mess.
Having spoken to my other iOS developer friends they have all stated it is time to move as far away from IB as possible. It has done nothing but screw them over. They think I am a fool for attempting to stick with IB as long as I have. I really just wanted to get the current project off the books but that is not going to happen. I can try and blow away the current table with a normal view then reattach the segues to the new view and leave it at that but that seems a new waste of effort.
I am going to have to learn auto layout. It is the new Apple way of doing things. It is the only hope if Apple decides to ever come out with a new resolution, which I really think they should. People are expecting HDTV on their devices. 1024x768 on the iPad mini is not cutting it anymore.
Maybe someone will come out with an excellent layout manager for iOS that will solve a number of these issues. At this time I don't care about WYSIWYG at the start. Something that is easy to code and maintain is what I want. I enjoyed working with MigLayout. I converted over 300 Java desktop screens from old NetBeans format to MigLayout at a previous company. I find the Android layout managers more difficult that MigLayout but still serviceable. The new Android Studio does a really nice job showing me a preview of my screens as I edit the XML. The layouts work and scale on various device sizes.
Done with my rant. Off to code NSLayoutConstraints.
Subscribe to:
Posts (Atom)