Develop Reference

Cheap but programming rich phone?

You think to yourself: what this question has to do with programming? Let me explain.
I had a SE K770i and tried to write a software on it that records sound and sends it to the server. And it occurred that the development framework on this phone limits and makes it hard to send big chunks of data.
So now i use older phone. But would like to start write some kicking bad-asses software for some new technology. So i figured out i ask you guys what is the most programmer-friendly hi-tech phone right now that is cheap and popular.
What the phone needs to have:
good software development documentation
must be cheap
must have recording, touch screen, video and sending data via internet support
must have nice access to all this resources from source code
must be popular
And it should NOT be Apple, because i can't effort 200 dollars a year to write some apps and don't like the whole verification think.
What hi-tech, cheap phone is a right way for a mobile developer these days?

As HW goes, perhaps this one which is a cheep android phone which received a lot of positive acclaim http://en.wikipedia.org/wiki/ZTE_Blade.

Given the recent developments with symbian and Nokia, I think it might be a decent bet to develop for the Android platform. Given the features you list, either the Google Nexus or any of the Samsung Galaxy series phones would be a good fit. On the android developer website though, google lists the Nexus as the device that one should test all apps on, especially since (IMO, I could be wrong) it is closest to Android-and-nothing-else. Other phones, such as Samsung etc., have Android but also some other APIs on them.
Update: Since you mention a price <= $500, I would suggest the Google Nexus S or a Samsung Galaxy Pop/Fit etc. That would fit nicely in with your price range.

Android Tablet or iPad for Kiosk Device

We want to place a device in a store that operates as sort of a kiosk device. As in customers walk up to it and start interacting with our custom app. The app could be developed for Android or the iPad, so I'm trying to decide which one to use and would like comments on the following ideas:
Is it possible for Android or iOS to access services over the USB port? This would enable us to disable the network.
Is one particularly better for 24 hour always on?
I like the iPad as I think its supply will be more constant as we move forward and need to replace devices due to ones gone bad. Also, our app will probably work on future generations of the iPad. With Android, I'm not sure there will be that sort of consistency from the tablet vendors.
Kiosk mode? I think with the iPad by putting it in a kiosk case that removes access to the home button and turning on the restrictions we'll get what we want. What about Android? I'd rather not have to get into rooting devices and replacing their firmware.
Remote control? Any way to remotely control iOS or Android in a standard means? Our app will be a client to a master server which will obviously be able to control the app somewhat (when used purely as a display device to a customer, controlled from behind the counter).
My feeling is that neither Android tablets or the iPad is best suited for this. Are there other options?

I will try to answer your points, but know that I am probably biased towards Android, because that is where my experience lies.
With Android 3.1+, at least with the Xoom, you have full USB host capabilities. Things like USB flash/hard drives, keyboards, mice, even digital cameras, all work. If you need custom interop with a USB device, you could go as far as to write a driver for it.
24 hour always on is not good for any device with a battery, but neither is better in this situation.
While android apps are forward-compatible, bad programming practices and/or deviations from "vanilla" Android software and hardware CAN break forward compatibility. That being said, if you grab a Google Experience device like the Xoom, you won't meet as many surprises.
In Android 3.0, the navigation bar is built-in at a low level, and it is not possible for apps to remove it. Therefore, it is trivial for anyone to break a "software nanny."
I know that it is possible to control android devices remotely, but without knowing your specific needs, I can't really offer more information than that.
Good luck!

iPad NOOO believe me I am a convert to Apple for my home and business but when we went to launch kiosk the iPad FAILED Big Time.. Here are a couple of little (Big) issues we ran into.
If the device reboots you cannot auto launch you iPad app since Apple does not allow that.
There is a serious memory leak in the iPads browser. We were running javascript / CSS3 and it cratered intermittently. I literally spent 2 hours "today" on the phone with Apple getting the MAJOR run around. I finally said let me speak to an Enterprise Sales Manager as my project could mean thousands of iPads and I got NO WHERE. One Apple employee even told me they don't have enterprise sales managers.
If those weren't enough even though we are just in the proof of concept phase, we are already getting request for other options. These other options are going to require access to the OS which Apple yea right. We are moving to Android immediately.
Sorry Apple I love you but you loose here.

If your using an Ipad you should consider if it can support the power for the USB thing. Watch this Using Powered USB Port

Your idea about putting the tablet behind another piece of glass/plastic is neat. To then deal with remote controlling, you might consider doing some Bluetooth programming.
My mobile development has been primarily with iOS, so I am biased toward that SDK. I will mention that the data/sync/charge port for iOS has (I believe) never changed. Your Gen 1 iPhone sync cord works on your iPhone 4... and your iPad or iPad 2. So, in terms of third party hardware, you may see more consistency with Apple.
I haven't found a good answer regarding whether it is easier to do Bluetooth programming for iOS or Android, but I think to stay cost-effective, you might see which one is more open to third-party devices. Here is an SO post/answer about iOS and third-party Bluetooth devices; I've not found anything on Android regarding third-party Bluetooth remotes, but considering a lot of hardware running Android is third-party, your chances from a naive perspective seem pretty good. Here's the Android Bluetooth API.
Buying an iOS or Android handheld to remote control an iOS or Android tablet does seem a bit steep, but then again, maybe not. Cost also depends on your ratio of remotes to tablets. 1:1? 1:N? N:1? N:M?
The lowest end iPod goes for $229 as of May 20, 2011. Android does have more variety in terms of hardware. You may be able to get a cheap Android phone with no service plan to act as a Bluetooth remote for an Android tab.

I have provided a solution for the kiosk mode using iPad here Lock-down iPhone/iPod/iPad so it can only run one app
I am afraid that I don't really know for Android if the same thing is possible.
To address the issue of crashing applications you can use an exception trampoline (see discussion here https://blog.compeople.eu/apps/?p=275) to catch the crash and reboot your app.
If the entire device is restarted however then other apps that are on the device can be started and will subsequently be locked in.
To answer your other points:
You can use a configuration profile to control network access. Force it to use a VPN or Proxy that only allows your custom app with embedded credentials to use. That way other network access can be prevented.
Your concern over future compatibility is spot on. The Android marketplace is so fragmented then maintaining a fleet is difficult.
If you have an app that is behaving as a server and is locked in then remote control is possible.

We manufacture tablet kiosks that support both android and iPad devices. In fact we are the only iPad kiosk that has achieved apple approval.
Generally speaking i think you will have an easier time with an iPad as the software and hardware will remain more consistent over time. Which is important if you have to change out a fault unit or deploy more kiosks 6 months or year from now when the original device is no longer manufactured.

Android in industrial embedded environment

what do you think about using android in an industrial embedded environment?
I'm thinking, for example, about a vending machine with a touch screen monitor. I can think about many advantages:
It would increase the ease of making an advanced user interface
Android provides tuned libraries to handle task like low power internet connection or encrypted connections
Thanks to dalvik VM, it is easier to run on different HW platform (Arm9 - Arm11 - ....)
but there are also some cons like:
Android is not thought for a mission critical environment (like a device handling money)... at least not to some extent.
If not kept up to date, the software may have some bugs that compromise safety. Issue is worsen by widespread adoption.
Someone might regard Android as resource hungry compared to a real time implementation of linux, with code written in C rather than java.
On the internet you can find some resource on the subject, but most is out of date:
http://www.hsc.com/Portals/0/Uploads/Articles/Android-Porting-on-Embedded-Platform_v2_0633850602027036930.pdf
http://www.androidforembedded.com/whitepaper/android-for-embedded.pdf
anyone has direct experience on the matter or can link me to some resource? What do you think about it guys?
Cheers,

I know of a Swiss company - Noser Engineering AG, which provides development of Android Software for embedded devices. Also check-out their showcase android to market

Android can definitely be used in a non-cell phone device. There will be pros and cons that you can find all around the web, which could be discussed during weeks.
On our side, we have been playing with Android for a while now (from the port of the OS on custom ARM board to app dev) and we see real interest from customers. Regarding reliability, as in any embedded device, it is important to validate it by yourself against the use cases that your system will have to deal with.
Eventually, if cons make you decide not to move to Android, you can have other ways to develop interesting HMI such as QT which runs efficiently great HMIs.
Anyway, you can check out our website (http://www.adeneo-embedded.com) and contact us if you need some help.

Touch screens in anything industrial is pretty much out of the question, believe me. You'd just get laughed at and wouldn't be able to sell it. Luckily, a vending machine isn't an industrial application and there a touch screen would be more suitable.
If you just want a touch screen with some GUI pre-made, there are probably 1000 companies already making such products, no need to re-invent the wheel. It would need to be > IPx5 classed too, if you want to put it outdoors in the rain and snow.
The main challenge for this kind of application is the money transactions, not the user interface. You should start there. What good money transaction software is there already available on the market, and what hardware is most suitable for it? To handle the transactions will be the real software problem for this application. Anyone can make some GUI touch screen fluff and have it toggle some relays or drive a stepper motor.
Also, I reckon the market for this application will mainly need 1) reliability 2) reliability and 3) reliability. The design, user-friendliness, visual appeal and fluffiness may let you sell one machine to a customer, but reliability will make you sell several.

Android as a commercial game platform

I'm currently developing a small non-commercial game for Android which is based on OpenGL ES. Except for some minor issues (slow as crap emulator being the biggest) I've really enjoyed it so far and would love to continue developing for it.
The question is: What are your thoughts on the future of Android as an environemnt for the game market? I read an article somewhere that said that the IPhone is the preferred platform for games, but since I don't own a Mac and won't bother with some complicated work around to get it to work on Windows I'm currently not interested in it.
So, what do you think? Is it worth spending alot of time (and potentially money) on a larger Android game project?

Short answer: it's too early to tell. Technically this platform is neither better nor worse for games developer than iPhone. Both have some support for 3d graphics, both have good support for multimedia - just the language differs ObjectiveC or Java.
The problem is not in the technical capabilities though, but in the popularity of the platform and purely business decision if Android is a good gaming platform. iPhone certainly is and many people are making money on it already. Will Android be as popular and will people be willing to buy the game for some money is a good question.
There is some difference Android and iPhone users and developers. Android is more open platform and more software is free (or even open source). For iPhone most apps cost 1$.
So the expectations in the audience is different. Android users expect more apps to be free and will (most likely) pay only when software you give them is really worth spending any money at all. iPhone users are willing to pay this $1 even to try an app out, after all they bought Apple product that was expensive to begin with.
Will that trend continue? Or will the audience types converge as more paid apps appear on Android market is an open question.
Finally -- there will be some millions of users of the Android platform eventually. So if you develop a kick ass game it will have its audience anyway. And if Android does not become a platform for games - that may even be beneficial for you, because you'll have no competition.

In my opinion it is worth it.
As #Marcin said, Android is more of a open platform then iPhone. And it's easier for developers to start with developing applications and putting them on the market.
But it means the market is populated with a lot of crap applications. And then, there are really shiny jewels too. They get good scores, are blogged/twitted about and are popular.
So, in my opinion, if you got an idea for a good game, go for it. If you put it on the market though, consider putting (at least a 'lite' version) in the free area (people in some countries are unable to even access the paid applications market).
the below part is completly my own opinion and you can simply skip it
There are some 'cool' games on mobile platforms that I love to play. As for me, there are few important things to watch for when developing such a game, that aren't this important in more 'traditional' gaming, on a console or PC:
it should be easy(fast!) to start and stop. If I play it at a bus, it could be just 1 stop. If it starts right away and then doesn't take 5 minutes to stop it, it's a +
one more thing about rapid start/stop. If I quit the game, then come back, give me a chance to continue where I stopped. No need to ask if I wanna save/load last game. Make it default, I can always start a new game if I want, can I?
controls - even that accelerometer-using games are fun at times, try to play it in a crowded place. like a bus. Touchscreen elements should be large enough so even the thick-fingers can use it. If they are - it's a +
for long time I was trying to realise why playing Bejeweled, or Puzzle Quest, was fun and enjoying, while many of their clones were simply irrytating. The diffrence was a tiny piece of user interface - in Bejeweled the pieces you got are both diffrent colors and shapes. They are much easier to "operate" (in a Bejeweled way) then, say, screen full of diffrent color triangles. If you make a game like this, make the diffrent pieces differ in many ways, not just one (diffrent shapes with same colors would suck even more; red triangles, yellow circles, blue squares and black skulls is a way to go - in my opinion)
it's a mobile device, connected to either WIFI or 3G network, you can use the internet to at least show/save highscores. But - remember - sometimes there's no network, we're in a diffrent country with roaming turned off or on the bottom of the ocean. Make the game work even there

Thanks for the replies!
I myself believe that the marketplace will gain momentum once there are more Android phones on the market, though my biggest fear is that it'll end up like Xbox Live Indie Games were 90% of the games are of below avarage quality, which of course affects it's reputation in the gamer community.
One thing I don't understand is why there isn't some kind of pre-approval before letting the application or game onto the market place. I understand that they want the people not the company to decide what should be allowed to be uploaded, but then they could let the users be the reviewers so that there is atleast some quality checks before release.

The iPhone has the advantage of a huge market (approximately 10x the android one at the moment) and even better most of those users have already given apple their credit card so they are ready to buy. Getting android users to spend .99 is hard. Depending on the game, you can make decent money (50-100/day) off of ads. The first is likely to change with more android phones and more android carriers(Verizon would be huge for the US market)
Technically Android is a bit slower (Java versus Object C) but with the NDK you can get decent performance. The iPhone has better opengl support (1.1 and 2.0 on the GS) while android is more of a 1.0.

There is an interesting article about Android as a games platform on Gamasutra.
Developing Games for Android

Is it worth purchasing Google Android Dev phone? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've been intrigued by all the android world since I first learned about it and would like to get my hands dirty developing for it. The question that comes to mind is if it's worth buying the unlocked phones that Android sells directly or not.
Those phones (link) quoting the Android page:
Run and debug your Android™
applications directly on a device.
Modify and rebuild the Android
operating system, and flash it onto a
phone. The Android Dev Phone 1 is
carrier independent, and available for
purchase by any developer registered
with Android Market™.
Please note that this device is
intended for development purposes, and
may not include certain features found
on consumer Android devices.
So will it be worth it to purchase one of those as a tool for app testing as opposed to developing and testing just on Eclipse or one of the other IDEs and emulators.
-Have you tried it, do you own one?
I'm assuming they have the same specs as the HTC Dream and the HTC Magic, since they look exactly the same although they have a 'developers edition' custom black design not that I really care about the design for this particular item.
All comments are welcomed,
Thanks in advance.
Update:
I'll leave it open until tomorrow to see if there are any more answers, then I'll just pick the most voted since it's really a subjective question with no good or bad answer.

It depends what sort of applications you wish to develop. I find that the emulators very accurately reflect how things work on genuine devices; you can seamlessly connect to either an emulator or a dev phone using the command line tools, the Eclipse tools, the debugger etc.
Also, while you can flash your dev phone to a new OS version, HTC often lag behind (e.g. there's still no 2.0 image available) and it's much easier and faster to just use the emulators. The emulators also allow you to create and test with different screen resolutions, whereas the two dev phones available are only "standard" resolution.
I find it's quite rare that I need to use my ADP1 dev phone for development -- my rooted consumer HTC Hero works fine for most of the development I do.. allowing me to pull files from the device etc. Though the only reason I use my Hero rather than an emulator is because I've been working on an app that uses audio recording functionality.
However, where having a physical device would help is where you need to do specific stuff regarding the camera, audio hardware, orientation and compass sensors, GPS, wireless network access and so on. Should you need to connect a debugger to work on hardware-related issues like the above, then you would definitely need a dev phone.
Overall, it's definitely worth buying an Android phone for testing and demonstration purposes, but whether it's a development phone is up to your requirements.

If you plan on developing apps that you intend to put on the Android marketplace, it's absolutely critical to test on real hardware. You can get away with developing on the emulator for quite a while, but at some point, you'll want to use a real device.
That being said, you can use any android phone for development. There are some restrictions on locked devices, but if you're simply developing against the SDK, any phone will work. With android, you can install an apk directly on the phone without special permissions, so the only real advantage to a dev phone is that you can install new roms without having to root the phone.
Personally, I'd hold off on purchasing one of the older dev phones. From what I understand, they only support up to SDK 1.6, whereas the Droid and some of the other new phones are supporting SDK 2.0 ++.

Wait for the release of the Nexus One from G. The latest rumors are that it'll be released on Jan 5th. So it's just a week or so.

I think that you need a real android device whether it's the dev phone or another handset but a real phone is primordial. The emulator is great but you can't get an idea about the execution speed of your app until you use it on a real phone.
As said before there are a lot of rumors about the nexus one so wait and see!

As for which phone to buy (assuming you're going to get one) I think ablerman is right. I'd wait until January to see if there is going to be some new hardware available.
With regards to the more general question of should you buy one, I think it depends on what you're doing. For the most part, the emulators are fine. They can emulate GPS (you can even load KML to simulate a path), SMS, phone calls, etc. They cannot however emulate acclerometer/compass/orientation sensor data and actually will crash (actually I believe it hangs...) if you try to run code that relies on it. Also, it's difficult to actually debug phone-call related functionality without the dev phone.
They're good phones, I've used the Dev phone 1 (the G1/Dream) and it's nice. It also is a bit faster than the emulators and if you're writing something like a game, it would be really good to test it on the actual hardware.
All in all, it just depends on what you're writing. They're definitely fun to play with regardless as you can do pretty much ANYTHING you want on them.
Good luck with the decision!

I've been developing with the emulator since June. I've found it to be a very near substitute for the real deal, and it's easier to switch between handset configurations/versions. However, not knowing how quickly my apps will run is a concern for me.
The reason I've personally held off buying a handset is that 2009 was the wrong year to buy one. I have a feeling 2010 will very much be the long-awaited "Year of the Android".

+1 to Christopher and I will add - the emulators are great but having a physical phone will give you instant access to the Android Market to verify publishing, statistics and user comments. I also believe using your own app on a physical phone will help you to develop a better app. You do not need a development phone - but at least one physical phone - absolutly.

FYI. Belgium is one of the few countries where it is possible to buy any mobile unlocked. Indeed, the Belgian regulators forbid the forced bundling.

One more Pros for buying a real developer phone :
HierarchyViewer does not work on user builds (i.e. with devices
available in stores.) This is for security reasons.
See the original thread
Hierarchy viewer can be very useful if you have problems with layout being slow, although I don't think it would worth buying a real Developer phone only for this.
As some people made workaround for that problem : https://stackoverflow.com/a/7801475/62921.