I absolutely hate McAfee antivirus. It sucks your CPU dry. This is the second company that I have worked at that uses this pile of crap. It makes my machine nearly unusable. I have used other anti-virus software that does not cause this issue.
McAfee insists on looking at every JAR file. Since they really are ZIP files it wants to open and unzip and look all the damn time. It is killing me. We had the tech team set up some exemptions and that worked for a bit but I have a feeling they got wiped out and I am back to not being able to write code. Anything using JAR files is super slow. I can't get any work done this morning so I decided to bitch on my blog instead.
I don't get viruses. I don't download stupid crap. I don't fall for scams on the internet. I just want to code but today I can't do that due to a piece of crap software that as NEVER during my time using it ever caught anything on any computer that I use EVER. I have put up with this crap for year and I hate it, hate it, hate it.
There has to be a better way for it to ignore stuff it has looked at 50 times already in a single day. Come on people, your software sucks and it is ruining my productivity. It has never helped me in the 6+ years I have been tortured by your crap.
Wednesday, November 28, 2012
Saturday, November 24, 2012
Only doing Android work - what a change of pace
At my new position I am only doing Android development where before I was doing Android / iPhone and desktop Java. First off it is a bit weird only having one computer, one IDE, one mouse and one keyboard to deal with. Everything is the same each day. You don't have to mentally switch gears multiple times a week.
What it does make you think about is pushing the one platform you are on even farther than before. I was always in a bit of a rush. I needed this working on both iOS and Android so I got it working on each but maybe not the best on each. Now I can say "I need this working on the Android and I need to to work and look the best possible." I don't care if what I am doing it pain in the behind on iOS, there is another team to worry about that. I don't have to think about desktop Java at all.
I am finding this new mentality is really helping me discover areas of the Android platform I had not had the time or energy to investigate in the past. I have been playing around with animations. We need to swap an image view between the front and back of a check. I started with a simple one, changed it to a fade in / fade out as suggested by another developer then I switched it again on Friday to a simple animation that makes it look the check is flipping. I am pretty happy with the current iteration.
The other bonus is I have the ear of a second Android developer. Being the solo mobile guy at the last place had a number of disadvantages. No one to bounce ideas off of, do code reviews, suggest a better way, a new animation, better color schemes, different layout ideas etc. The other guy has a lot of different Android experience than I do. He had worked with JSON before so got that part running quickly. I had done custom controls and a lot of layouts so I had that handled. We both know to use styles, the string table and other XML files to keep things clean.
The code we inherited looked like it was the first Android project written by this off shore team. We had a lot of general clean up to do before we even wanted to touch the guts as they did not follow any of the general Android guidelines.
We are finishing up the process of making this a real Android app. They locked all the screens into portrait. That may be acceptable for a game but not for a main text based application. The iPhone team locked it all into portrait too because doing both portrait and landscape under iOS can be a pain. Sure, there are some gotchas in Android but it is pretty darn flexible on the layout side of things and it is easy to create the directories you need. Plus we are working on having it look nice on phones and tablets. The iOS team is not doing a universal app so iPad owners will get the less the satisfactory 2x experience.
They are not too worried about Android tablets telling us there is little demand there. Not sure they are looking forward enough. There are going to be a lot of 7" tablets from Google and Amazon under the tree this year along with iPads and iPad minis. I know I use my tablet a lot around the house and I figure more and more people will be using them too. For this battle I am making sure it looks nice and is operational on a tablet. It is not tablet optimized but if you use a tablet I don't want you to scream and run away when you fire up this application.
I would suggest they do a universal app for iOS too but I think that will fall on deaf ears. The current team is very new to iOS, learning it on the fly in fact. Since I sit a converted break room with the other Android developer and two of the iOS team I get to hear their issues. Most of them I know about having done iOS development for a year. At least they are going after iOS 5.x and above and can use the new memory management aspect. The current code does not but all new code can. That will be a huge help. I was using that on the final iPad project I worked on at the old job and I know I could get used to doing it.
The one thing I really miss from the old job is dual 24" monitors. I have a dual screen set up now, the laptop screen and a 21" screen with a less than stellar resolution. The Android emulator barely fits on a screen height wise. Developing means you have a ton of windows open: Outlook, instant messenger, browser, text editor for notes, Eclipse, emulator, music player, command prompt, paint program, etc. These little 1400x900 screens just don't cut it. A a contractor I am considering picking up a bigger screen and hauling it in just to keep my self slightly sane. Companies need to realize how important screen space is to a developer. My dual screen set up at home is a better configuration than I have at work and that is kind of sad.
All in all it has been a good experience so far. They have work lined up so I know there is plenty to do. I am becoming a better Android programmer every day and using more of what the SDK has to offer. As long as I am growing at a job I am happy. The people are friendly and having another Android coder next to me has be a huge help.
What it does make you think about is pushing the one platform you are on even farther than before. I was always in a bit of a rush. I needed this working on both iOS and Android so I got it working on each but maybe not the best on each. Now I can say "I need this working on the Android and I need to to work and look the best possible." I don't care if what I am doing it pain in the behind on iOS, there is another team to worry about that. I don't have to think about desktop Java at all.
I am finding this new mentality is really helping me discover areas of the Android platform I had not had the time or energy to investigate in the past. I have been playing around with animations. We need to swap an image view between the front and back of a check. I started with a simple one, changed it to a fade in / fade out as suggested by another developer then I switched it again on Friday to a simple animation that makes it look the check is flipping. I am pretty happy with the current iteration.
The other bonus is I have the ear of a second Android developer. Being the solo mobile guy at the last place had a number of disadvantages. No one to bounce ideas off of, do code reviews, suggest a better way, a new animation, better color schemes, different layout ideas etc. The other guy has a lot of different Android experience than I do. He had worked with JSON before so got that part running quickly. I had done custom controls and a lot of layouts so I had that handled. We both know to use styles, the string table and other XML files to keep things clean.
The code we inherited looked like it was the first Android project written by this off shore team. We had a lot of general clean up to do before we even wanted to touch the guts as they did not follow any of the general Android guidelines.
We are finishing up the process of making this a real Android app. They locked all the screens into portrait. That may be acceptable for a game but not for a main text based application. The iPhone team locked it all into portrait too because doing both portrait and landscape under iOS can be a pain. Sure, there are some gotchas in Android but it is pretty darn flexible on the layout side of things and it is easy to create the directories you need. Plus we are working on having it look nice on phones and tablets. The iOS team is not doing a universal app so iPad owners will get the less the satisfactory 2x experience.
They are not too worried about Android tablets telling us there is little demand there. Not sure they are looking forward enough. There are going to be a lot of 7" tablets from Google and Amazon under the tree this year along with iPads and iPad minis. I know I use my tablet a lot around the house and I figure more and more people will be using them too. For this battle I am making sure it looks nice and is operational on a tablet. It is not tablet optimized but if you use a tablet I don't want you to scream and run away when you fire up this application.
I would suggest they do a universal app for iOS too but I think that will fall on deaf ears. The current team is very new to iOS, learning it on the fly in fact. Since I sit a converted break room with the other Android developer and two of the iOS team I get to hear their issues. Most of them I know about having done iOS development for a year. At least they are going after iOS 5.x and above and can use the new memory management aspect. The current code does not but all new code can. That will be a huge help. I was using that on the final iPad project I worked on at the old job and I know I could get used to doing it.
The one thing I really miss from the old job is dual 24" monitors. I have a dual screen set up now, the laptop screen and a 21" screen with a less than stellar resolution. The Android emulator barely fits on a screen height wise. Developing means you have a ton of windows open: Outlook, instant messenger, browser, text editor for notes, Eclipse, emulator, music player, command prompt, paint program, etc. These little 1400x900 screens just don't cut it. A a contractor I am considering picking up a bigger screen and hauling it in just to keep my self slightly sane. Companies need to realize how important screen space is to a developer. My dual screen set up at home is a better configuration than I have at work and that is kind of sad.
All in all it has been a good experience so far. They have work lined up so I know there is plenty to do. I am becoming a better Android programmer every day and using more of what the SDK has to offer. As long as I am growing at a job I am happy. The people are friendly and having another Android coder next to me has be a huge help.
Saturday, November 10, 2012
Life at the new job and a Galaxy Note as my testing device
Life at the new job has been interesting. They did not have an official place for me to sit on the first day so I took over the office of a guy who is on vacation. They found a place over in customer support so I moved there for a bit and now will move to a more permanent home in what use to be a small conference room that is being divided into 4 cubes. I will be in there with another Android developer and two iPhone developers. Will help us share a lot of ideas.
For my main testing device they gave me a Galaxy Note - original version not the new II. For some reason I thought it was going to be much larger as all the reviews jump all over that. It is larger than my main phone, a Galaxy S Vibrant. I actually like the size. Larger than my phone but not a tablet. I have been using it a lot a night to see what I think of it as I have considered getting a Note II when it goes on Black Friday sale, or at least I hope it goes on sale.
I wish the S-Pen worked a bit faster. I am hoping it does a better job keeping up on the Note II. On the model I have I must slow down my standard writing speed to have it draw what I think it is going to draw. I should not have to adjust to what the device can do, it should keep up with me. I have used the phone as a mini whiteboard. Again, drawing speed is a little slow but if I match the pace it works well. Using it to jot down notes at home is also handy, it sits right next to me and saves me from hunting down paper to remember something like "out of cat food". You can easily erase mistakes in your drawings too. I think this could be a great feature.
As far as a testing device it is really nice. Samsung seems to be very quick to grab back memory you once used and to kill activities as you move between them. It allows me to simulate low memory usage that would occur on a phone. This really comes into play as I am doing a lot of importing of images from the camera activity which is one area you can quickly run into memory limitations. I have been able to fix all the issues I have run into and make my code much more low memory proof than previous code I have written. Allowed me to learn all sorts of interesting things about Android programming.
After using the phone for about a week I would say it is a winner. I have been using it at night instead of my Xoom when I put my son to bed. At that time I am generally reading web pages, using Pulse or maybe playing a game. Being able to do that with one hand is really nice. I don't know if a 7" tablet would allow me to do the same thing or not as I don't have access to one. The Note fits in the hand without cramping. The screen is very bright and readable. I only charge is once a day. Web pages tend to be read in landscape mode but that works just fine. You get the side to side space you need for most websites but you do have to to a bit more scrolling vertically as you read pages. Nothing that is annoying, just something to keep in mind.
After I have time to test the S-Pen drawing speed on a Note II and it goes on sale I will probably buy one as my next personal device. I love the Xoom tablet and use it a lot. My phone is getting older and it only runs 2.2 which is pretty crappy. I need to use some of the new Android OS features to keep up with the programming world.
Working strictly on mobile development at my job has been nice. No shifting gears between iOS, Android and desktop Java during the day. One keyboard, mouse, language and IDE to keep straight. I am happy I know Objective C so I can look at the code and see what they did as my first project is a conversion of the automatic check deposit functionality, thus me taking a lot of pictures. I am sure my cube mates are sick of hearing the sound of a camera shutter as am I. Friday morning I fixed my threading issue so I stopped taking pictures and started looking into the server API for send the deposits.
Being as I am a contractor I get to work Monday which the perms have the day off for Veteran's Day. I will be happy when I convert to a full time person allowing me to have all the bank holidays off like I did when I worked in the stock market industry.
For my main testing device they gave me a Galaxy Note - original version not the new II. For some reason I thought it was going to be much larger as all the reviews jump all over that. It is larger than my main phone, a Galaxy S Vibrant. I actually like the size. Larger than my phone but not a tablet. I have been using it a lot a night to see what I think of it as I have considered getting a Note II when it goes on Black Friday sale, or at least I hope it goes on sale.
I wish the S-Pen worked a bit faster. I am hoping it does a better job keeping up on the Note II. On the model I have I must slow down my standard writing speed to have it draw what I think it is going to draw. I should not have to adjust to what the device can do, it should keep up with me. I have used the phone as a mini whiteboard. Again, drawing speed is a little slow but if I match the pace it works well. Using it to jot down notes at home is also handy, it sits right next to me and saves me from hunting down paper to remember something like "out of cat food". You can easily erase mistakes in your drawings too. I think this could be a great feature.
As far as a testing device it is really nice. Samsung seems to be very quick to grab back memory you once used and to kill activities as you move between them. It allows me to simulate low memory usage that would occur on a phone. This really comes into play as I am doing a lot of importing of images from the camera activity which is one area you can quickly run into memory limitations. I have been able to fix all the issues I have run into and make my code much more low memory proof than previous code I have written. Allowed me to learn all sorts of interesting things about Android programming.
After using the phone for about a week I would say it is a winner. I have been using it at night instead of my Xoom when I put my son to bed. At that time I am generally reading web pages, using Pulse or maybe playing a game. Being able to do that with one hand is really nice. I don't know if a 7" tablet would allow me to do the same thing or not as I don't have access to one. The Note fits in the hand without cramping. The screen is very bright and readable. I only charge is once a day. Web pages tend to be read in landscape mode but that works just fine. You get the side to side space you need for most websites but you do have to to a bit more scrolling vertically as you read pages. Nothing that is annoying, just something to keep in mind.
After I have time to test the S-Pen drawing speed on a Note II and it goes on sale I will probably buy one as my next personal device. I love the Xoom tablet and use it a lot. My phone is getting older and it only runs 2.2 which is pretty crappy. I need to use some of the new Android OS features to keep up with the programming world.
Working strictly on mobile development at my job has been nice. No shifting gears between iOS, Android and desktop Java during the day. One keyboard, mouse, language and IDE to keep straight. I am happy I know Objective C so I can look at the code and see what they did as my first project is a conversion of the automatic check deposit functionality, thus me taking a lot of pictures. I am sure my cube mates are sick of hearing the sound of a camera shutter as am I. Friday morning I fixed my threading issue so I stopped taking pictures and started looking into the server API for send the deposits.
Being as I am a contractor I get to work Monday which the perms have the day off for Veteran's Day. I will be happy when I convert to a full time person allowing me to have all the bank holidays off like I did when I worked in the stock market industry.
Thursday, October 25, 2012
Changing jobs
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.
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.
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.
Subscribe to:
Posts (Atom)