Saturday, November 20, 2010

MigLayout - you really should try it

At my new job they used the NetBeans GUI editor to create their panels / dialog boxes. At some point they started to use MigLayout now want to replace all the existing panels. I started with around 220 and now have about 160 to convert.

So why use MigLayout? Why not GridBagLayout or one of the other Swing layouts? My previous job used GridBayLayout for everything even when a very simple BorderLayout would work. I wanted them to switch to MigLayout but it never happened. I have used MigLayout for a few of my side projects and I really like it.

MigLayout Pros:
  • Handles all your layout needs - if you draw it you can lay it out
  • Very simple to learn - string driven
  • Easy to read even if another developer did the initial layout
  • Very concise making for compact code
  • Will handle Mac vs. PC differences in button layout ([Cancel] [OK]  vs [OK] [Cancel])
  • Handles high DPI settings
  • Will handle insets for each OS (also a con, see below)
  • Easily lets you keep a set of controls to be the same size. You can have all buttons in a panel be the same width by putting them in a size group
  • Add special gaps to any side of a control. For some layouts you may want a little extra spacing above or below a control
MigLayout Cons:
  • Handles insets for each OS but the Mac uses large insets with can throw off look and will cause issues if you use setSize in your code for a dialog box. You can override the insets so you get the same look on every OS
  • Since it is string based you will not find out if you typed something in wrong until run time. Of course you are going to run the application anyway to make sure you layout is fine but your code is not validated by the compiler which is something you get used to with the base layouts
  • Another JAR file to include in your download
The Pros outweigh the Cons by a large margin. I have been able to take a screen shot of the current panel, drop it in Paint.NET on my second monitor and quickly type the new MigLayout code just looking at the screen shot. I don't have to sit down and draw out things like I did when I was doing a mix of BorderLayout, FlowLayout, GridLayout etc. I don't have to constantly do a row++ or column++ to add things to a GridBagLayout and I don't have to fill in some big GridBagConstraints object or pass a pile of parameters to a help method to add a component. Really it is as simple as this:

setLayout(new MigLayout("ins 5", "[grow]", "[][grow][]");
add(new JLabel("Enter comments:", "wrap");
add(textAreaScrollPane, "growx, growy, wrap");
add(okButton, "gapabove 10, split 2, aligny right, sg btn, tag ok");
add(cancelButton, "sg btn, tag cancel");

This would be a standard comment entry dialog with a label telling you want to enter, a text area in a scrollpane that grows vertically and horizontally to fill the space and the [OK] and [Cancel] buttons that are the same width right justified in the dialog box. The buttons are tagged so each OS can swap the order if needed. I put a 10 pixel gap above the [OK] [Cancel] button area to separate it a bit from the text area. The "sg btn" just puts them both in the same size group named "btn" you can name it whatever you want and have as may different size groups as you need. This is a tiny example. I have layouts at work with over 50 controls in them, everything is handled perfectly and all of it sizes as the user sizes the dialog box with no problems.

See a bunch of funky numbers in there? See me incrementing rows and columns? Nope, pretty clean stuff. Check out the MigLayout website to find out more. I am not associated with the program in any manner other than being a happy user for many years.

Thursday, November 11, 2010

Objective C is like programming with the dinosaurs

I finally got the HTML / GZIP / XML parsing to work on the Mac. Do you know what the problem was? I was not using the same version of the TouchXML code as the person who did that left. I described some of those issues in the last post.

This morning I downloaded an even newer version of TouchXML figuring that was the issue. It still crashed. I installed Wireshark on my PC and on the Mac. I though maybe the server call was hosed so I looked at the packets and they were fine. That meant it was the code at fault. Another developer and I worked on tracing through things and figuring out the odd way you have to query the contents of variables. If I would have known how to do that earlier I would not have messed with Wireshark.

For me it is hard to fathom why the XCode IDE is so behind the times. It is just not anywhere near as powerful as IntelliJ, Eclipse, NetBeans, Delphi, Borland C++ or Visual Studio. It is not that I am not a Mac guy it is just that I have used a lot of very nice IDEs. Have Mac developers not used other IDEs? Eclipse and IntelliJ are available on the Mac, I have used both on the Mac. They work just as well on that platform as they do on the PC. XCode is crappy. It does not have may hot keys, it does not support tabbed files, it loves to pop up all kinds of windows and the debugger stinks.

I just want to see the contents of my variables but it does not show them even things as simple as string don't show up. I used the GDB window to type "p (char *)[(NSString *)[element data] UTF8String] to see the data in a String! This is just crazy to me. In Java or C# I just hover over the variable and I see the contents. Even if it is just a NSString I still have to do "p (char *)[data UTF8String]. I had some really deep variables and it was a real pain to type all the typecasting to get any data out of them.

The IDE works, the debugger works, it is just a pain to get to your data.

Getting to the actual issue - the debug window was trying to tell me the problem. I thought it was crashing in a method but it turns out the method did not exist. Of course I am used to the compiler telling me with a very obvious compiler error not having this happen at run time in a debugger window. The new version of TouchXML changed from childElements to children and elementCount to childCount. I thought it was crashing in the childElements call getting back 0 elements thus annoying the loop. This is due to Objective C being a dynamic language. Part of my learning experience but man was it an annoying experience.

This is a bizarre situation, I was upgrading by accident as I had no idea what version the original developer used. Normally you would know you are upgrading and when the debugger complained you would spot the problem quickly. I was just happy I was able to get things to compile initially. I thought that meant I had the proper TouchXML code.

Things are not all rosy still. It is giving me back blank strings when I request the "name" for one of my XML items. I will have to chase that down too. Not crashing, just a blank string. No idea what is going on there. Just getting to a variable with no depth is bad but getting to a collection of things is going to be a major hassle. I hope I can find it quickly in the morning. Probably just leads to other issues and I am not going to trust the code until I can run it through all of its paces.

I will check it all in, including the new TouchXML classes tomorrow if I can get the XML strings to display. It is making us wonder if it would have been better to start this application from scratch instead of trying to update the code. That is pretty sad actually. Not something that I have done in other languages in a long time, just punted, unless the code was just super crappy. I think the code is generally OK it is the IDE and the language this is fighting me.

Tuesday, November 2, 2010

Initial iPhone Development Experience from a PC Java guy

At my new job I get to do some iPhone development. Not new development but some enhancements to an existing application. So far it has been a real uphill battle.

First all the code was not checked in to SVN. That meant I could not compile things after the initial check out. Once I figured out you can click on a red (ie bad) file and do Get Info to see where it thought it should come from I was able to figure the missing images. Luckily they were checked in to the build directory - not that the build directory should be in SVN but it was. The other files are part of TouchXML. I figured that out using Get Info and was able to locate the files on the web. Then all the frameworks links had to be updated as it was originally done with the 3.1 SDK but I have 3.2 and 4.0 installed on the Mac Mini I am working on so I had to point to newer versions.

First I copied the TouchXML files into the ExtraLibs directory as was suggested on the web but figured that was not really optimal for others to use and get from SVN so I moved them under the project. If we do more than one iPhone app that needs to share them we will move them into a shared project but there are no plans to do that at this time.

Next up was figuring out the xCode IDE. It does not appear to be as full featured as Eclipse or IntelliJ. All the basics are there but it seems to be missing some of the advanced things I am used to like multiple open files in tabs and hot key support for various actions. The keyboard actually drives me bonkers. I have a regular PC keyboard hooked up so at least I have a full set of keys and don't have to press extra FN to get to things I use on a regular basis. Pressing HOME - which I expect to go to the start of the line - takes me to the start of the file. I know, I just need to learn Mac keys but old habits are hard to break. I also have to press the Windows Key a lot to do things. Getting the hang of that.

I was able to get the program running in the debugger once I got all the libraries / frameworks linked properly to the project. It would run but accepted no mouse or keyboard input. I finally figured out I was running the emulator in iPad mode. Switching to iPhone mode and it worked. I thought iPad was just a big iPhone, sure app would maybe look ugly but should run. This is not the case. Don't have time to figure that out right now. It is my understanding the last build for the original developer works fine on the iPad. The IDE keeps switching back to iPad mode though which is really annoying. When I start it up to a rectangular emulator I know it is wrong, shut it down, change the target and start it up again.

Once you are familiar with the Android on screen keyboard the iTouch one seems really limited. All keys show as uppercase on the keyboard, the only way to know you are in uppercase is to see glow around the Shift Arrow. Keys only do one thing so you have to switch to symbol mode to get numbers and another mode to get some symbols. On the Android you can just hold down on a key and get to the associated symbol. Plus I love Swype now that I have started to use it. Finally the keyboard on the iTouch totally covers up where I am typing so I can't even see what I am entering and there is no Next button so I have to type then press ENTER then press on the next entry field and type. Data entry, which I have to do for user name and password really stinks. I have an iTouch at home and have used it a lot in the past. After using my Android phone I am much happier with it for data entry. Personal choice.

I finally got it to log in but now it crashes processing some XML data from my HTTP request. The data is coming back in GZIP format, because that is how I asked for it, but I don't think it is getting converted to plain text. I am in the bowels of code trying to figure that out. Maybe the TouchXML handles it or maybe some other code. I could be I got a newer version of TouchXML. The original author is not at the company and no one else has worked with this code. I don't know Objective C and have not worked on the Mac much so I am pretty handicapped at this point. It is a challenge.

For me the whole Android configuration was much easier and since I already know Java I could get up and running pretty quickly. I also knew Eclipse and the PC keyboard allowing me to start typing and experimenting right away. I started on a clean app so I could learn at an easier pace. Finally I did not get tossed a 3rd party library right at the start which meant I could write tiny bits of code and to see what happens without the worry of multiple frameworks in my way. And I comment my code, none of the iPhone source for this app is commented and it is not using iPhone standards for naming conventions making it extra fun.

The app is working on the iTouch. It is the code from the original author. I don't know if my build will run on the iTouch and it is just the emulator that is screwy. I can't put my code on the iTouch as I don't have the signing certificate set up yet. This was a fresh install of the development environment. It is nice the Android does not care about signing for you to run and debug on your device. Maybe the iTouch does not either, just seemed to be annoyed without that set up during my initial attempts. I need to get that working to see if I have to run that way for things to work but I also hate to kill the one working instance I have of the application.

Interface Builder (IB) is also another new area. Since the iPad version was not working I thought maybe some of the event connections got broken and I decide to hook them back up. They were not broken but I did learn a bit about IB while trying to figure that out. I also saw some on the net needed to remove / re-add connections to make things work so I went through that whole experiment. Threw me off when hitting the (+) button did nothing. It is a dragging starting point and not so much a button. You drag over to your classes and it will pop up things you can connect to. All makes sense once you know what to do.

I will say I was a bit surprised at all the information I could find on the Web. I was under the impression that Apple was keeping a lot of information under lock and key. The whole programming on the iPhone was supposed to be shrouded in mystery. I did not find that to be the case. Pretty much anything I did a search on via Google popped up numerous results with quick answers. My misconception probably came from a few years back when a lot of the SDK talk was NDA making it hard to publish much without raising the ire of Apple.

SVN support in xCode seems workable but again does not work as it does in a lot of other PC based IDEs. I was finally able to check in code - mainly the missing files - but it took some doing. I think part of the issue was the build directory files being checked in which annoyed SVN on both the PC and the Mac side of things. There were temp files with ~ in them which SVN does not care for in the least. I cleaned it up using TortoiseSVN on the PC then the PC and Mac both worked. There just are so many more free tools on the PC to get things done in this area and again I have used them in the past. It was easy for me to quickly give up on the Mac, do it on PC and move back to Mac to move forward on the app again.

Am I saying the Android development environment is totally superior to the iPhone or the PC is better than the Mac? No, I was more familiar with everything about the Android environment - IDE, Windows and Java so it was easier for me. Not being a Mac person I am learning a whole new way of looking at things. I am not saying right or wrong, just different and difficult at this stage. I have learned enough programming languages and frameworks in the past that I figure I can get up to speed in a reasonable amount of time. I will learn the keyboard, various short cuts and all the cool stuff you can do with Interface Builder, xCode, Objective C and the iPhone SDK. Right now I am in the newbie struggle mode but I will enjoy the challenge and hope to find many things on the Mac that I miss on the PC.

Maybe I should port my Android game to the iTouch which would give me a balanced picture of development on both sides. I will have to wait until we give the Mac Mini to QA at work and I start using a Macbook for my iTouch development so I can do that conversion at home on my own time. Of course I still have some performance and other tweaks I want to do to my Android version and I would like to finish them up first but starting a new job has meant I am mentally burnt out by the time I get home so final touch up to a game is really not high on my list. Making money from a game is so I should push myself...