Being the solo mobile developer at a job is not easy. I had just gotten used to having a couple of developers around me at my previous contract position. Everyone had bits and pieces of experience in different areas so you would quickly get answers to questions without doing a Google search. They might have some sample code laying about from another project or just know how to do it.
Sure the big boss here wrote the initial iOS code that I have been cleaning up and adding features against but I rarely get to speak with him and he has no Android background. I have been working on the Android port this week getting stuck on silly things that the guy I worked with at the last place would have handled with ease as he had a lot of background in those areas. Now that the core networking is in place I can start moving forward at a pretty good clip.
A real feeling of isolation when you have developers all around you but they either don't know the language (Objective C) or the framework (Android SDK) thus you can't really bounce any ideas off of them. Sure I can hit them up for general business knowledge or Java questions but not for the meat of the development cycle.
For my Android work I have been using Android Studio. I know it is a 0.1 release but that is really just the Android plug-in side of things. The over all IDE is at version 12 and I have enjoyed using IntelliJ in the past. I like the dracula theme as far as colors go.
The ability to edit layout XML and see the results side by side in the preview window is super handy. I have gotten that to generate crash reports from time to time but they did not kill the IDE or lose any of my work.
What I miss from Eclipse is the new class wizard. It asks for the base class and interfaces and lets you quickly build things out. I have asked about this on the IntelliJ forms and they basically stated you can do all of that via a number of steps. I want a Wizard. I also want the auto add of the Activity to the manifest. I should not have to do all that work manually every time I add a new activity to the project. Since this is a new project that has been happening a lot.
The Log Cat filter seems pretty iffy too. I turn it on to filter out things but it forgets about that between program runs so I have to go back to "No Filters" then back to my filter again. It is silly how much junk the emulator kicks out into Log Cat. Since I am using the HAX high speed emulator I get a ton of extra stuff.
I was happy to get the upgrade to 0.11 this morning. Good to know there is active work on Android Studio and I am sure it will continue to improve. I have been using it at home on my Win7 64 bit PC and my Macbook Pro at work. Both seems to run equally well.
Showing posts with label mobile. Show all posts
Showing posts with label mobile. Show all posts
Wednesday, May 29, 2013
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.
Monday, September 10, 2012
Mobile Native vs. HTML 5 - can't hide your JavaScript code
I have the scheduler viewer running in HTML 5. It scrolls around and paints rather nicely. Performance of the HTML 5 canvas control is acceptable on various devices. I had fun experimenting with the Canvas control but one thing really bothers me - anyone can grab my JavaScript code. Sure I could obfuscate it and make it a little more difficult to us but it is still there in your browser ready to steal. A pretty printer will reformat the code to be readable with silly looking variable and method names.
This is just a little sample app so I don't really care too much about this code but what if the code is logging in to your server and making a lot of API calls? Better not do all of that in JavaScript. That means you need to hide things on the server side. Basically you need to move a bulk of the work up there so others can't have free reign on your data. That puts more of a load on your server instead of on the client. We don't want slow clients but JavaScript has really stepped up its processing speed so putting what you can on the client makes sense.
I ran into this situation at a previous company. We wanted to do an HTML interface to our stock market data. Some one looked over the code as it was sent to their PC, figured out most of the API and started grabbing the 20 minute delayed stock market data off our feed. They were not using the API correctly and crashing our server. Going through all the fun of legal was really dragging out so we explain to the thief how to use the API to stop crashing the server. I was not involved in all the legal aspects so I don't know the full story or the final resolution. Given enough time we probably could have gotten the server to not crash and to obfuscate the API even more but that generally turns into a losing battle.
With a Native Mobile App this is much less likely to occur. Yes, you can sniff the wire and try to emulate the calls that way. People will do that. You can use HTTPS instead of HTTP which helps. It really is a lot harder to figure out an API from an App though, you just don't get to see the source code.
This does not make HTML 5 + JavaScript the wrong way to go. This does make you really think about JavaScript if you are accessing a lot of data off your server. If you are just doing an interactive web site, a game or something else where the loss of data is really very minimal and you don't mind others scanning your source code then go for it.
Before you decide HTML 5 is the way to go for a mobile project think about your level of source code exposure. Decide how much you need to handle on the server. Decide what code is harmless for others to see on the client side. Don't go in blind and try to solve these issues the week before your first release.
This is just a little sample app so I don't really care too much about this code but what if the code is logging in to your server and making a lot of API calls? Better not do all of that in JavaScript. That means you need to hide things on the server side. Basically you need to move a bulk of the work up there so others can't have free reign on your data. That puts more of a load on your server instead of on the client. We don't want slow clients but JavaScript has really stepped up its processing speed so putting what you can on the client makes sense.
I ran into this situation at a previous company. We wanted to do an HTML interface to our stock market data. Some one looked over the code as it was sent to their PC, figured out most of the API and started grabbing the 20 minute delayed stock market data off our feed. They were not using the API correctly and crashing our server. Going through all the fun of legal was really dragging out so we explain to the thief how to use the API to stop crashing the server. I was not involved in all the legal aspects so I don't know the full story or the final resolution. Given enough time we probably could have gotten the server to not crash and to obfuscate the API even more but that generally turns into a losing battle.
With a Native Mobile App this is much less likely to occur. Yes, you can sniff the wire and try to emulate the calls that way. People will do that. You can use HTTPS instead of HTTP which helps. It really is a lot harder to figure out an API from an App though, you just don't get to see the source code.
This does not make HTML 5 + JavaScript the wrong way to go. This does make you really think about JavaScript if you are accessing a lot of data off your server. If you are just doing an interactive web site, a game or something else where the loss of data is really very minimal and you don't mind others scanning your source code then go for it.
Before you decide HTML 5 is the way to go for a mobile project think about your level of source code exposure. Decide how much you need to handle on the server. Decide what code is harmless for others to see on the client side. Don't go in blind and try to solve these issues the week before your first release.
Subscribe to:
Posts (Atom)