Today is my last day at my current position. I learned a lot about mobile development being the sole developer for both the iOS and Android product. I have also written a game that is free out on the Android market called Grid Hunt and am working on another Android side project.
For my current position I do WebStart Java Application work too along with project management and graphics artist work. For the new position I will be start with Android specific programming. They already have the iOS side up and running. I will work on converting that to Android. They plan on having the mobile team being able to work both sides of the mobile OS platforms. I already have a nice head start here.
I am excited and nervous to change jobs. Excited as I will no longer have to do all the project management and graphics artist work. I will start with a specification and get to code away. I also will not be switching IDE, keyboard, mouse, monitor and programming language multiple times a week. This allows me to really hammer down on Java / Android under Eclipse. I really like Eclipse and find it to be super fast for my programming style. IntelliJ IDEA is fine too, which is where I did my desktop Java work, Xcode stinks but AppCode was pretty good for iOS development. I will not miss Xcode and its various limitations nor will I miss Objective C as a primary programming language. I will of course still see it as I can pull that code and look things over during the Android conversion.
Nervous because you have to learn the ins and outs of a new environment. What version of Agile are they using? Bug tracking? Version Control? Who is who when it comes time to ask questions? How locked down is your development machine? When do people eat lunch and where do they go? What are core business hours? Can I work from home? Do others comment the code and use comments when checking in code? Braces on separate lines? TAB or SPACE? Is the current code base solid or kind of spotty? Is there a solid understanding of OOP? What format does the data come from the server? Does each developer have a piece of test hardware or is it shared? Do they allow wearing of headphones or music at all? Where is the bathroom, break room, copy room, etc? Weird office politics? General sense of humor? Dress code specifics? Flexibility of work hours? Time reporting rules? Base hardware? Web surfing rules?
Yeah, it is going to be an interesting day on Monday as I begin to figure things out. I will get back into the flow of being a kick tail programmer pretty soon and then it being at work will become and easy habit and I will know a ton of new people. All of 20 blocks from where I currently work so I can visit the old staff over lunch easily enough. I am ready to be a full time Android developer. Always more to learn about that platform.
Thursday, October 25, 2012
Tuesday, October 9, 2012
Dialogs - gather data or do everything?
Should a dialog box simply gather data or should it do the processing on the data too? I have seen it done both ways in code with things intermixed in the same project. It gets very confusing when the two styles are mixed.
What exactly do I mean? A dialog box has a number of controls such as text fields, check boxes, lists etc. They gather information from the user as to what to do next such as printing a document, searching on criteria or choosing data to add to a table.
In the actual dialog box code you can also have it act upon that data and do the print job, perform the search or write data to the table but should you? I think the dialog should not perform the operation, it should only collect and validate the data.
Why do it that way? This keeps the processing separate from the UI. It allows you to run the print, search or table add in a headless manner, you don't need the dialog to appear to perform the operation.
So why do people chuck it all in the dialog? Because you already have all the data. Why pass it back and forth between the dialog and the operation? Boy that is annoying! Yes, there is more code involved to pull the data gathered out of the dialog. You can use separate method calls for each data item, a map or other collection type to get it back to the calling program. It really is not that big of a deal and it will save you a lot of time later when you need the operation separated from the UI. Lazy programming will come in bite you in the behind every time.
Don't cheat and make methods on the dialog object static so you can call them without invoking the dialog. That is a misuse of objects.
A lot of times the operation can take a lot of time. You want to show a busy state in the application and possibly run it on a background thread. Maybe the processing - such as printing - can run while the user does something else. If you leave this all in the dialog code that crazy UI sits on top of your app until processing is over. That is not very friendly. The dialog does not need to know about how the processing should be done. Is it quick and easy, does it take a long time and must complete before they move on to the next step or can the whole operation run in the background while the user moves on to the next task? Different data set sizes may need different processing actions. Don't lock all of this down in the dialog.
What exactly do I mean? A dialog box has a number of controls such as text fields, check boxes, lists etc. They gather information from the user as to what to do next such as printing a document, searching on criteria or choosing data to add to a table.
In the actual dialog box code you can also have it act upon that data and do the print job, perform the search or write data to the table but should you? I think the dialog should not perform the operation, it should only collect and validate the data.
Why do it that way? This keeps the processing separate from the UI. It allows you to run the print, search or table add in a headless manner, you don't need the dialog to appear to perform the operation.
So why do people chuck it all in the dialog? Because you already have all the data. Why pass it back and forth between the dialog and the operation? Boy that is annoying! Yes, there is more code involved to pull the data gathered out of the dialog. You can use separate method calls for each data item, a map or other collection type to get it back to the calling program. It really is not that big of a deal and it will save you a lot of time later when you need the operation separated from the UI. Lazy programming will come in bite you in the behind every time.
Don't cheat and make methods on the dialog object static so you can call them without invoking the dialog. That is a misuse of objects.
A lot of times the operation can take a lot of time. You want to show a busy state in the application and possibly run it on a background thread. Maybe the processing - such as printing - can run while the user does something else. If you leave this all in the dialog code that crazy UI sits on top of your app until processing is over. That is not very friendly. The dialog does not need to know about how the processing should be done. Is it quick and easy, does it take a long time and must complete before they move on to the next step or can the whole operation run in the background while the user moves on to the next task? Different data set sizes may need different processing actions. Don't lock all of this down in the dialog.
Thursday, October 4, 2012
Which way to go for mobile permissions?
Which way do you like better for mobile permissions - Android or iOS? Android has you build the permissions into the program via the manifest file. iOS asks for permissions as the program runs. Both have pros and cons.
Android
Pros:
Developer decides on a list of required permissions, must adhere to them
Compiler enforces permissions
User gets to see all permissions at time of program install / upgrade
Permissions as static and included in app binary, don't have to be stored in associated data area of device
Cons:
Permission list may change during OS updates
User forced to read list during install, most ignore and just install, later complain you did something crazy
Some permissions are not granular enough
Some permission you would like to have but are not required to run - how to handle that?
iOS
Pros:
Developer codes away, does not really have to think about it
Old cheating programs are now caught when action is requested
New permissions can be prompted with OS upgrade
Cons:
User is bothered during program run, might scare them
Developers were able to cheat before, can still cheat until OS upgrade catches them
OS trust instead of IDE support, your app could fail due to user saying NO, defensive programmer for run time issues
Need special storage to keep track of each permission granted per application
User has to go under settings, privacy to find what they have granted if they want to make changes
I am undecided on which way I like better. I am happy to see iOS is now addressing this issue. Previously it was the wild west in iOS land. I just saw a prompt while running my code as I allow you to choose images from the gallery to attach to medical cases. What I am doing is innocent but I can see where programs could easily abuse this privilege. I was pleased to see the prompt appear and to have it only prompt once.
Android
Pros:
Developer decides on a list of required permissions, must adhere to them
Compiler enforces permissions
User gets to see all permissions at time of program install / upgrade
Permissions as static and included in app binary, don't have to be stored in associated data area of device
Cons:
Permission list may change during OS updates
User forced to read list during install, most ignore and just install, later complain you did something crazy
Some permissions are not granular enough
Some permission you would like to have but are not required to run - how to handle that?
iOS
Pros:
Developer codes away, does not really have to think about it
Old cheating programs are now caught when action is requested
New permissions can be prompted with OS upgrade
Cons:
User is bothered during program run, might scare them
Developers were able to cheat before, can still cheat until OS upgrade catches them
OS trust instead of IDE support, your app could fail due to user saying NO, defensive programmer for run time issues
Need special storage to keep track of each permission granted per application
User has to go under settings, privacy to find what they have granted if they want to make changes
I am undecided on which way I like better. I am happy to see iOS is now addressing this issue. Previously it was the wild west in iOS land. I just saw a prompt while running my code as I allow you to choose images from the gallery to attach to medical cases. What I am doing is innocent but I can see where programs could easily abuse this privilege. I was pleased to see the prompt appear and to have it only prompt once.
Wednesday, October 3, 2012
What will the iPad mini bring to the table?
Have you already hammered out adjustments so your app will run on the iPhone 5? Has it been submitted to the App Store? Are you waiting on it to be accepted? I have updated our app to run on the iPhone 5 but have not tested on actual hardware yet so I want to wait for that to happen before I submit.
It did get me thinking about the iPad mini. First off if it actually exists what resolution will it be? Should it be double the size of the iPhone 5? That makes some sense to me as they are looking at videos and deeming the wide screen presentation is the way to go. Will it be same resolution as the iPad 3 in a smaller package? Makes it easier on tablet development and really that resolution is fine for a 7-8" screen. Heck there are much smaller Android phones running higher resolutions than the iPad.
Let's say they go with a new resolution. You get to update your app yet again. The main app I have is universal - same code runs on iPhone / iTouch and iPad. The update to iPhone 5 was pretty simple as I try to avoid hard coding. Since I also wrote the Android version I already need to think resolution agnostic. I tend to not think in absolutes coming from a PC background. Hopefully my code will port quickly.
I have special checks in the code now for the iPad as the status bar is the same height in portrait and landscape mode on the iPad where as it changes height on the iPhone based on orientation. I really wish you could query controls for their current / minimum / preferred dimensions. Maybe in a future release of iOS.
At this point I think I am better off waiting to submit anything to the Apple Store until the iPad Mini release is confirmed for October or nothing happens. I can submit one app and catch all the new resolutions. I will have to decide if just testing via the simulator is enough. Since I know my app runs fine, as far as speed is concerned, on actual devices how far can I trust the simulator? It gets tough for a small company to buy a lot of testing hardware. I know I have already put a lot of faith in the various Android emulators and so far have not run into issues and I can see from our Google Analytic data that our users have a wide range of Android devices and we have yet to have a layout related issue reported to us.
Apple recommends testing on actual hardware always. I really do see their point but at some juncture you have to punt. I don't have an iPad 1, 2 and 3 along with iTouch Rev 1 - 4 and iPhone up to 5. I have already given up testing on each type. As a small shop, I am the only mobile developer, we just don't have a bunch of techies upgrading their phones in lock step with Apple. I don't know anyone with an iPhone 5 at this time. Heck my personal phone is only 2.2. I do have a Jelly Bean tablet.
It did get me thinking about the iPad mini. First off if it actually exists what resolution will it be? Should it be double the size of the iPhone 5? That makes some sense to me as they are looking at videos and deeming the wide screen presentation is the way to go. Will it be same resolution as the iPad 3 in a smaller package? Makes it easier on tablet development and really that resolution is fine for a 7-8" screen. Heck there are much smaller Android phones running higher resolutions than the iPad.
Let's say they go with a new resolution. You get to update your app yet again. The main app I have is universal - same code runs on iPhone / iTouch and iPad. The update to iPhone 5 was pretty simple as I try to avoid hard coding. Since I also wrote the Android version I already need to think resolution agnostic. I tend to not think in absolutes coming from a PC background. Hopefully my code will port quickly.
I have special checks in the code now for the iPad as the status bar is the same height in portrait and landscape mode on the iPad where as it changes height on the iPhone based on orientation. I really wish you could query controls for their current / minimum / preferred dimensions. Maybe in a future release of iOS.
At this point I think I am better off waiting to submit anything to the Apple Store until the iPad Mini release is confirmed for October or nothing happens. I can submit one app and catch all the new resolutions. I will have to decide if just testing via the simulator is enough. Since I know my app runs fine, as far as speed is concerned, on actual devices how far can I trust the simulator? It gets tough for a small company to buy a lot of testing hardware. I know I have already put a lot of faith in the various Android emulators and so far have not run into issues and I can see from our Google Analytic data that our users have a wide range of Android devices and we have yet to have a layout related issue reported to us.
Apple recommends testing on actual hardware always. I really do see their point but at some juncture you have to punt. I don't have an iPad 1, 2 and 3 along with iTouch Rev 1 - 4 and iPhone up to 5. I have already given up testing on each type. As a small shop, I am the only mobile developer, we just don't have a bunch of techies upgrading their phones in lock step with Apple. I don't know anyone with an iPhone 5 at this time. Heck my personal phone is only 2.2. I do have a Jelly Bean tablet.
Tuesday, October 2, 2012
Getting images on the Kindle Fire Emulator
While testing our app on the Kindle Fire Emulator I needed to verify my image processing was working correctly. By default the emulator has no images in the gallery.
Using Eclipse in the DDMS perspective click on emulator-544 in the Devices tab. In the File Explorer tab find the mnt directory and expand it. Find sdcard under than and then Pictures. You can use the "Push a file onto the device" button to copy image files into that directory.
You can also put them in the mnt\sdcard\DCIM directory or the mnt\sdcard\DCIM\Camera directory. The final directory might not exist but you can create it in the File Explorer.
At this point you will need to stop and restart the emulator. It does not appear to rerun the sdcard scanner while running looking for new files.
Make sure when you create the emulator that you enable "Keyboard support" in the hardware section of the AVD or you will have to click on individual letters to type anything which gets boring rather quickly. You can disable this is you need to test with the soft pop-up keyboard.
Using Eclipse in the DDMS perspective click on emulator-544 in the Devices tab. In the File Explorer tab find the mnt directory and expand it. Find sdcard under than and then Pictures. You can use the "Push a file onto the device" button to copy image files into that directory.
You can also put them in the mnt\sdcard\DCIM directory or the mnt\sdcard\DCIM\Camera directory. The final directory might not exist but you can create it in the File Explorer.
At this point you will need to stop and restart the emulator. It does not appear to rerun the sdcard scanner while running looking for new files.
Make sure when you create the emulator that you enable "Keyboard support" in the hardware section of the AVD or you will have to click on individual letters to type anything which gets boring rather quickly. You can disable this is you need to test with the soft pop-up keyboard.
Subscribe to:
Posts (Atom)