My Phonebot Plus app is now available on the Android Market/Google Play. Phonebot is an application that allows you to create applications directly from your phone. It includes features such as a script language and interpreter, visual screen layout, and database management. For Phonebot Plus, I've added some useful development tools in addition to what you get with standard Phonebot, along with more display formatting properties. New stuff:
Be forewarned: All of this wonder will cost you nearly One US Dollar. Gasp!
Check out the Developer's reference for full details on what you can create. The main Phonebot page also lists several of its competitors and semi-competitors that are out there. I also posted about it on Reddit and Hacker News.
I had this field cornered when I first started but it's gotten pretty active recently, with several full-fledged Java IDEs available now. The benefit that I think Phonebot offers is with its high-level script language, script generators, and visual layout editor. These are all features that eliminate typing and let you create applications quickly.
So at work I was talking about the Android apps that turn your phone into a web server. This could be used for impromptu scatternets at meetups or any rally where coordination is key. Control moves from the cloud to peer-to-peer.
I've tried two of the apps, and although I love the concept they are very limited. First, they only serve up file lists from a configurable root folder. This is nice for sharing pictures but not for much else. Second, and more limiting, they're only visible over WiFi. I haven't done enough remote access development on the Android, but I'd assume that socket connections (from locked phones) are blocked by the providers. However, this post from Think Android does just that. More research needed.
Thinking about phone servers while jogging on Sunday, I had the idea to create a DNS system for Android phones. After registering a unique name, you could give out a URL and publish whatever you want through a name server (e.g http://nameserver.net/my_id/index.html). A local service on the phone would act as a DDNS updater, pinging the name server whenever your IP changed. Thoughts then ran to web app development on the phone and I was back to Phonebot as the natural solution to developing shareable applications. Host a signup sheet or chatboard. Create a GPS map of group members. Write group games on-the-fly.
I just published an Android app that lets you develop applications from your phone. It's a simple IDE with a script language and interpreter, visual screen layout, database management, etc. It's a v1 that has had a beta tester of just me, so beware.
You can review the Developer's Reference for a quick idea of what's what. And it comes with some sample applications for basic examples of what can be achieved.
(The marketplace is refusing to update images and text right now. Apologies if the copy editing is wonky.)
Just released a pay version of the GPS bookmarking app I first published three weeks ago. The new version, ArgotPlus, adds several nice organizational features (a tagging system, viewing neighboring bookmarks, cardinal directions, and a link to maps) and will be the version I actively develop.
Interesting report from yesterday, all handheld OSes except Android have lost market share in the last year:
I just published my first Android app to the Android Market. It's an idea I had a year or so ago and, after getting my new HTC Incredible a few months ago, finally got the opportunity to write it. It's called ::Argot and it's a tool to bookmark locations to revisit them later. I had the idea during last year's Cabbage Town Chomp and Stomp. It was packed as usual and after wandering around I could never find my way back to where friends were camped out. The v1.0 is pretty basic, but I plan on adding features and creating a more robust premium version to maybe sell for a buck.
I've been very happy with the development tools for Eclipse and there's a strong community of developers and code samples on the internet. I was seldom stumped with a problem for very long. It felt good to get back to application development after doing primarily web development for so many years.
After the updates to Argot, I'll probably create a front-end for RadioWave. I've been listening to streaming stations in the car, and it would be nice to "dial" through their schedules to find something to listen to.
The new TOS for the upcoming iPhone OS 4.0 introduces additional restrictions on how developers can create applications for the device. Any application must be
Apple's choice, if we can divine intent, was a strategic move to lock developers in to the iPhone over other mobile platforms. Cross compiler companies' choice is to lock developers into their cross compiler over other, single platform compilers. Developers are offered a clear benefit by choosing the latter's lock in, not so with the former's.
I don't have a dog in this race, but I'm a developer and love the tech and social aspects of our mobile web present and future. Apple can do whatever it wants with the iPhone/Pad, just as Microsoft did whatever it wanted years ago to attempt to lock in developers with the Visual J++ mutation of Java. However, it's important to note the costs developers should consider when choosing the route of lock in. Short-term gains may have long-term drawbacks.
It's bad for competition, it's bad for developers, and it's bad for consumers.
Everyone fears The Ignorant Boss, several updates to the post also worth reading
Geeks insist the iPad is for "their moms" to use as they stand in line to purchase one (or more) for themselves. This self-deceit is used to justify the purchase of what would otherwise be considered a grossly limited netbook. When developers choose to develop on the iPhone for the chance to get rich (many do), they also choose to navigate the capricious business dictates of Apple. Developers generally don't seek out arbitrary corporate limitations when choosing projects either fun or profitable, but with "do what works" as a common mantra, neither are they an overly principled bunch. We'll see if Android benefits from this.
Tim Bray's left Sunoracle for Google; working on the Android. In his announcement of the switch he denounced the
walled garden that is the iPhone. He re-visits the thoughts I had concerning the iPhone, more sharply:
It's a sterile Disney-fied walled garden surrounded by sharp-toothed lawyers. The people who create the apps serve at the landlord's pleasure and fear his anger. ... I hate it. Non-Android-bashing is his job now, so take that for what it's worth. RWW reported that the Droid (unlike the Nexus One) basically matched the iPhone's sales when you compare the first 2-1/2 months of each. An unlike comparison, but all we have to judge is imperfect metaphors at this point.
In the Slashdot discussion of the Tim Bray story, several people take this opportunity to take up what is becoming an old chestnut of internet flame wars. One, criticising disingenuous arguments defending the iPad's limitations:
That the iPad is crippled because it's simplified for grandmothers (it's not, it's designed for internet addicts who already have at least one computer); that the walled garden is for security (it's for profit and lock-in)...[ 1 ]
And another pointing out the feeling of missed opportunity:
The iPad is a nice device. But there are a lot of things inherently wrong with it. And I find it worrying that Apple, otherwise often a pioneer in technology is capable of ruining an otherwise good device and wants to severely restrict what I do with it. I think there's something very wrong with that.[ 2 ]
This second, and certain thread replies, gets to an interesting point. Many who have been criticizing the iPad (ahem) have been treated as idealists or fanatics. Apple holds a special position among geeks, and so criticizing them can hold special weight. Like asserting that Beethoven was a hack or Einstein dull-witted, criticism of Apple can appear to be merely attention-grabbing. I had mentioned before that my old iRiver MP3 player restricted copying from it to a computer. This is an archaic idea that would not be tolerated in today's marketplace. If a company decided to create such a consumer-limiting device, any geek would immediately rail against it on principle. If it were made by Apple, those geeks would be mocked.
From the original news story, I noted what I called the backlash backlash: criticism of the iPad was the first order backlash, and criticism of that criticism was the second order. I've always been befuddled by criticism of criticism in the arts. There, it represents a gall that another person might have an objective assessment of what some believe to be subjective: aesthetic quality. Other, more general possibilities explaining hostility towards criticism are (1) that you can't criticize unless you are an artist, or (2) that critics are simply arrogant and negative--tearing down that which is better than them. A complement to this belief is that praise of a work of art is both true and valid.
The standard library implementation that comes with eVC 4.0 does not include the IOStream library. That means no [i|o]stringstream and no [i|o]fstream. The biggest loss with stringstream is the type-safe number conversion. fstream offers similar benefits wrapped in a, generally, clear-cut interface.
I had mentioned before about the delicate nature of CE with regard to memory corruption--the OS will allow the overruns and such until your code eventually locks. Walking through can be very slow and tedious. Another instance where silent memory corruption can occur is when you reference COM objects in your code. I had a code path the bypassed ::CoInitialize(), checked all returns on CreateInstance(), and still ended up with corrupted memory.
All of these memory problems were bugs in my code. However, they would have failed immediately and at the point of the error in a desktop application. There's just less room for error on CE.Continue reading "Limitations and caution on CE"
In two previous entries, I had discussed tips on developing on Windows CE and trapping events from the Web Browser control. I had been researching integration of an HTML UI in a CE application for a hypothetical company I work for. Here are some details on what I've found.Continue reading "HTML integration in CE applications"
This entry is a repository for tips and resources on writing C++ code for Windows CE. I'll be continually updating it and reorganizing it as I find new information.Continue reading "Windows CE development"
This entry explains how to trap HTML element events in MFC using the Microsoft Web Control. This will allow you to respond to events such as button clicks and selection changes as they are fired by any element within a Web page.
Setting this up is mostly straightforward. The only tricks are making sure you get the Internet Development SDK from Microsoft's Platform SDK and that you use the correct element type in your HTML.
This was all learned recently, so there are some as yet un-explained caveats.Continue reading "Trapping element events from a Web Browser control"