Tag android (12)

FlightPredictor gets love as an "airport survival app"!
Mood: excited
Posted on 2012-05-30 10:15:00
Tags: windowsphone projects android
Words: 63

FlightPredictor is number 2 on this list of five airport survival apps! The blurb is nice and specifically calls out the airport maps, which I spent quite a bit of time on. It even lists all the platforms it's available on.

Based on my referer logs, a good number of people are reading the article and clicking through to the FlightPredictor page. Yay!

1 comment

FlightPredictor for Android was reviewed! (and I respond)
Mood: excited
Posted on 2012-02-15 20:06:00
Tags: projects android
Words: 839

Thanks to the magic of Google Alerts, I saw that FlightPredictor for Android was reviewed by Android Tapp! Excerpts and my comments below:

The app provides some of the basics you would expect, such as the ability to search for flights by either the flight number or by the route information, and you can search up to a day prior and six days ahead. It would be nice to be able to add flights booked further in advance so you have them entered and can forget about them until it’s time to travel, but that’s a minor complaint overall.
Interesting - you should be able to add them 90 days ahead. I noticed she tested it on a Galaxy Tab 10.1, while most of my development was on phone-sized screens, so I'm guessing either she didn't notice that you could scroll the spinner dropdown, or it's somehow broken on the Galaxy Tab.

I do like that you can access overall airport delays in a dedicated screen, so if you just want to take a quick look to get an overall picture of how on time the system is overall, or if there are any major issues you need to be aware of as a traveler, this is a quick and easy way to do it.
Yay! I added this feature mostly just because I thought it was cool.

Where this app separates itself from the flight tracking pack, however, is in the maps. When you travel, most of us will have to spend at least some time wandering around an airport waiting for boarding time. Having the full airport maps at your fingertips, without needing a Wi-Fi connection to access them, is a really, really nice thing. My only complaint is that right now, the maps are limited to a few of the major U.S. airports, although the developer has posted that more are going to be added in time.
Yay again! To be fair, there are more than 30 airports that have maps, so I think this hits almost all of the major US airports. (users: if there are airports you want to see, let me know!)

I did find that occasionally the maps themselves were a bit slow when moving between various sections, but the convenience of having them outweighed the wait.
Interesting - it's using a standard WebView to render the map images (easy way to get panning, zooming, etc.), so I guess it's not too surprising it can be on the slow side.

The app claims to use the Android notification system to let you know about delays, but to be honest, I found this part of the app a bit sketchy. This was the only thing that didn’t work well for me, with the app either not notifying me at all, or notifying me long past when the flight landed and the information was no longer relevant. I had a good network connection, but I can’t rule that out completely, so keep it in mind when you grab this one.
That makes me sad. I thought I tested the notification system a decent amount, but it's hard to test all situations...

Note that the free version allows for six flights before requiring an upgrade, so you should be able to get a good idea of whether it will work for you before you buy.
Woohoo. I'll probably do a similar thing for trial mode in the Windows Phone version.

The interface is very, very simple. It’s a dark background with lighter text, which was occasionally hard to read, especially for some of the links in blue. This is the one area where it feels like it could be a bit more polished and professional, instead of feeling almost like a “my first app” interface. Not to say it doesn’t work well, just that visually, it’s not the most compelling app out there. It does the basics, and that’s it.
Hah! No argument here, honestly. This area is the opposite of my strong suit.

AndroidTapp.com Rating

3.45 out of 5 stars

Should you Download FlightPredictor? Overall, this is a solid app that does what it says. I like the addition of the airport maps, but with all the real data coming from FlightCaster, which has an app of its own, I’m not sure this brings a whole lot of extra to the table. It’s a good app, but I wouldn’t call it the best of show, especially since you have to pay to track after six flights. If you’re a frequent traveler, however, this is worth trying out since it does do what it advertises with a minimum of fuss.
Wait - FlightCaster has an Android app of their own? I'm pretty sure that isn't the case, although there are a few other apps that use the FlightCaster API. But they all seemed pretty simple, and I think my app is considerably better than them :-)

Anyway, this whole thing has the feel of the Bluth family cheering over their stock being upgarded to "Risky", but I'm excited anyway!

0 comments

FlightPredictor: Android milestone, WP7 progress
Mood: cheerful
Posted on 2012-01-24 18:06:00
Tags: windowsphone projects android
Words: 267

FlightPredictor for Android has reached a milestone - as of the end of December payment, I've now officially made money on it! It cost $25 to register an Android account and I've finally made more than that on sales. Sales seem to be picking up lately: obviously the raw numbers are still pretty uninspiring, but progress is progress. Perhaps it's because of the four 5 star reviews it's gotten on the Android Market. I also sold one (yes, one!) copy on the Amazon Appstore, and am up to 11 cents in ad money from FlightPredictor Lite.

For Windows Phone, I've been hitting the app pretty hard, and have implemented a lot of features - enough, in fact, that I can make a list of everything I want to do before release. It's on a sheet of paper, but in case it gets wet or something, here it is:

- make it tombstone-safe (i.e. save state when backgrounded)
- show airport delays
- show airport maps
- will have to download these after app install - figure out how versioning will work!
- about screen (attribution)
- settings screen (necessary?)
- flight info - add when it was last updated, make sure nothing else is missing
- make live tile have an image with status/prediction for its background instead of text
- TODOs in code (down to 20 or so)
- show airline contact info
- make reloading flights on main page consistent
- send all flights (email/SMS)
- make real icons for app
- decide what to do about trial version and do it
- mutex in background agent for communicating? (see EvenTiles discussion)

So...still a long list, but these are all pretty well-defined tasks. Onward!

2 comments

Setting values on a view: webOS vs. Android vs. Windows Phone 7
Mood: curious
Posted on 2011-12-11 13:00:00
Tags: essay palmpre windowsphone programming android
Words: 574

Now that I'm working on porting FlightPredictor to a third platform (Windows Phone), I have a better idea of the differences between the platforms. This post is about one of the more common things to do: taking values in code and making them show up in a view.

For reference, here's a screenshot of the flight info page of FlightPredictor for Android:

This view is one of the most important ones in the app, and there's a ton of information on it. Let's focus on just one part: how to make the flight times (the "4:35 PM - 5:50 PM" in the upper-right corner) show up on screen.


webOS:
For a blast to the past, let's look at Mojo first. This is the old application framework that is only used for older phones today.

In Mojo, each view is an HTML page, so in our HTML page for the flightInfo view, we include the following:

#{-publishedDepartureTimeStr} - #{-publishedArrivalTimeStr}
(I'm deliberately omitting the layout stuff...maybe I'll cover that in a future post!)
The #{} syntax means to use the property from the templateModel of the scene. (the - means don't escape any HTML in the property). So, my Flight object has these properties, and when pushing the scene I call
this.controller.stageController.pushScene({name: 'flightInfo', templateModel: event.item}, event.item);
The event.item is the Flight object, and since I'm passing it as the templateModel, that's it! All in all, this is pretty simple - as long as the property's already defined in the Flight object, I only have to change one thing (the HTML source of the view) to get it to show up.

--

Now, let's look at Enyo, the new application framework that is used on the TouchPad (and some newer phones). In Enyo, views are defined by JavaScript that generates HTML. (for a real introduction, see Enyo Basics - From the Bottom Up) Here, the FlightInfo kind includes this for the view:
{name: 'currentFlightTimes', allowHtml: true, content: ''}
and then in the create code for the scene, we have:
this.$.currentFlightTimes.setContent( flight.publishedDepartureTimeStr + ' - ' + flight.publishedArrivalTimeStr);
Here we have two things to do, but it's still fairly straightforward to make new properties show up.


Android:

Things are considerably less happy here. First, we have to define the TextView in the layout's .xml file:
<TextView android:id="@+id/flightInfoCurrentFlightTimes">
Then we have to create a variable for this TextView in the Activity class:
private TextView currentFlightTimesView;
Then, in the constructor for the Activity class, we have to get the view:
currentFlightTimesView = (TextView) findViewById(R.id.flightInfoCurrentFlightTimes);
And finally, when we set a flight, we have to set the text on that view:
currentFlightTimesView.setText( flight.getOriginalDepartureTime().getTimeStr() + " - " + flight.getOriginalArrivalTime().getTimeStr());
So that's a total of 4 changes to make, in two different files. This is significantly more irritating than either webOS version, and it really shows up when you have ~20-30 of these to add to the view.


Windows Phone 7:
Back to a world of happiness: with data binding, we can go back to a Mojo-like model and just add this to the XAML:
<TextBlock Text="{Binding PublishedFlightTimes}">
Admittedly, in this case we'd have to add an extra property for this (or make two separate TextBlocks), but there are plenty of cases where I just want a property that already exists. In any event, it's much simpler than Android. Hooray!

So, the final count:




OSChanges
webOS - Mojo1
webOS - Enyo2
Android4
Windows Phone1 (maybe 2)

I would be very curious to see what the corresponding number is for iOS - is there a way to do simple templating?

2 comments

On a revenue basis, webOS >> Android
Mood: energetic
Posted on 2011-12-07 11:23:00
Tags: palmpre projects android
Words: 266

I worked for around 3 months on FlightPredictor for Android. It's not a particularly pretty app, but it is very functional, and I am proud of it.

Since I released it 3.5 weeks ago, I have sold a grand total of 20 copies. At $1.99 each, minus Google's cut and taxes, that amounts to around $20. (and I had to pay $25 to register in the Android Market, so I haven't even broken even) There's even FlightPredictor Lite, a free trial version with ads (that have made me 3 cents so far).

On webOS, a platform whose future has been very uncertain since August, and despite the fact that I haven't released any new apps in a while, and have only made minor updates to FlightPredictor HD (mostly adding airport maps at users' requests), and there's no free trial version, I'm still making $10 a day. Obviously there are a lot of factors helping me out there (TouchPad firesale, the fact that FlightPredictor HD is still a featured app and is in Pivot), but maaan. If I wanted to optimize for revenue, I should have doubled-down (ahem) on webOS.

I guess that makes FlightPredictor for Android somewhat of a labor of love, which is odd since I don't plan on getting an Android phone. It was fun to learn how to make an Android app, though, even if it was frustrating at times.

The Windows Phone version is coming along slowly (busy time of year), and I'm hoping playing around with a developer phone will give me more ideas of how apps generally work on WP7.

0 comments

FlightPredictor for Android followup
Mood: hopeful
Posted on 2011-11-29 14:33:00
Tags: projects android
Words: 231

After my last post about FlightPredictor for Android (thanks for the feedback, everyone!), I've decided to take the following steps:

- Submit it on the Amazon Appstore - the terms aren't great, but the more exposure, the better. The app makes much more sense to me on smartphones than it does on tablets, but it's sold pretty well on the TouchPad so I want to give it a chance on the Kindle Fire. It's currently going through the approval process and will be available...well, at some point.

- Free version: Last night I finished up FlightPredictor Lite, a free version with ads and a limit of 6 flights to add. Hopefully this will give people the confidence to upgrade to the real one.

I'm going to wait a bit to let things settle in (and make sure there are no more major problems to fix), make a few improvements, and then go on the attack trying to market it. The "build it and they will come" approach isn't really working - I've sold around 16 so far, and two of those were to family members :-)

Speaking of which, it is kinda cool having an app that people I know in real life can use. (well, more than one person) I guess that's one advantage to writing apps for a more popular OS...

Probably going to move on to Windows Phone stuff soon, modulo holiday goings-on.

0 comments

FlightPredictor for Android sales: not good. Maybe Amazon App Store?
Mood: disappointed
Posted on 2011-11-23 14:54:00
Tags: projects android
Words: 228

I released FlightPredictor for Android on Saturday. Since then, I have sold a grand total of...6 copies. (although it did get a 5-star review!) This is *ahem* a bit disappointing, and I've been considering some options.

- Marketing: the Android market is such a big place I'm sure it's easy for apps to get lost. Android users: where do you go to hear about cool new apps?

- Free version: I've heard that Android users are much less likely to pay for apps than those on other platforms. Maybe I should make a free version that has ads. I'm not a huge fan of in-app ads, though, and I can't imagine they'd make that much money. Plus, that's potentially a bunch more users to support. And other flight-tracking apps aren't free...

- Amazon Market: I'm also deciding whether or not to submit to the Amazon App Store. The terms are not favorable to developers, as Amazon can set your app to be any price they want. (hopefully not less than 99 cents?) But it's the only way to get on the Kindle Fire, and while I didn't optimize FlightPredictor for that big a screen, a beta tester used it on a 7" tablet and said it worked fine.

Maybe part of the problem is neither Google nor Amazon care that much about app sales?

Anyway, I'm more than open to suggestions.

4 comments

FlightPredictor for Android published!
Mood: proud
Posted on 2011-11-19 16:00:00
Tags: projects android
Words: 43

FlightPredictor for Android is now available!

alt="Available in Android Market" />


Thanks a ton to my beta testers - caught a lot of bugs that way! If anyone downloads it (hint, hint! :-) ) and has problems or questions, don't hesitate to let me know.

0 comments

finishing Android, starting Windows Phone 7. And happy car milestone!
Mood: stressed
Posted on 2011-11-14 10:40:00
Tags: car windowsphone projects android
Words: 320

I'm basically done with FlightPredictor for Android. I started almost three months ago, so one major takeaway is that apps take a long time to write. It took a bit longer since I hadn't done any Android work before, but most of the design was just copying the existing apps, so maybe that balances out?

To set the record straight, some of my Android complaints were unfair, and once I got into the swing of things I got things working in fairly short order. (although some still stand) So it's not a terrible environment to develop in, although Java isn't my favorite language, but having to design for a ton of different screen sizes with a ton of different OS versions combined with the fact that there doesn't seem to be many standards for interaction really made it a drag.

Oh, and I tried filtering a list on David's phone and it was very fast. I'd estimate the emulator is something like 20x slower than running on a phone. Which worked out nicely since I didn't have to optimize anything further, but it sure does make testing on the emulator painful!

Next up is a Windows Phone 7 version, which I've just started. I'm guessing with the holidays it will take a bit longer than three months, but since I'm already moderately familiar with WPF/Silverlight/C#, perhaps it will go faster.

--

My Prius hit 100K miles last week! I've been pretty happy with it - since I bought it 7 years ago it's only had a few problems. It's averaged just under 43 MPG over that time. A quick comparison with a Camry (which gets ~28MPG):



PriusCamry
Gallons per 100K miles23253571
Price for gas (at $3/gallon)$6975$10713

So I've saved more than $3500 on gas already, which is a bit less than the premium I paid for the car, but it's pretty close. Here's to 100K more miles!

1 comment

More irritations with developing for Android
Mood: irritated
Posted on 2011-11-05 16:32:00
Tags: rant programming android
Words: 593

I'm nearing completion of my port of FlightPredictor for Android. While things aren't as bad as they seemed when I started learning Android development and I'm able to make progress at a reasonable rate, two things popped up over the last few days:

- One of the activities in the app is choosing an airport. There are more than 900 to choose from, so I put them in a big list with a TextView on top so you can type to filter. On the emulator, filtering is very very slow (it takes around 5 seconds from typing something until the results change), and while it won't be that slow on an actual device (please?), it will probably be noticeable. So I wanted to put up a loading indicator that goes away when it's done.

Calling the filter to do its filter-y thing is pretty simple, something like

adapter.getFilter().filter(s);
where s is the string that's in the TextView. And you can pass another parameter to get a callback when a filtering operation is done.

But! If the user types in something like "bwi" in rapid succession, it will immediately try to filter on "b". (I tried to fix this problem for a while: the Filter class even has a setDelayer() method that does exactly what I want, but it's hidden...) While that's going on and the "w" is pressed, I call to filter "bw", and assuming the first request is still going on when "i" is pressed, I call to filter "bwi". When the "b" filtering is done, the filter (intelligently) then goes on to just filter "bwi". So this means I only get two callbacks that filtering has been done. So I have to essentially write a tiny state machine to keep track of, when I do a request whether there's one already pending, and if I've already done another one when there's one already pending.

I will agree that the code didn't take that long to write - most of the time was spent looking for some easier way because someone must have wanted to do this before, right? But no luck...

- FlightPredictor includes a bunch of maps of airport terminals. These are saved as image files, and there's around 20 MB worth of them. Unfortunately, as best I can tell, some (many? most?) Android phones ship with very limited space on the device itself, but come with a big SD card to store stuff on. (this is the case on David's Galaxy S phone, anyway) You can tell apps to install on the SD card, but this won't work in my case because I have a Service that runs in the background (to update flights), and you aren't supposed to let those kinds of apps install on an SD card because apparently any SD card apps get killed when the phone gets plugged in.

What I really want is to just keep the image files (stored in assets/) on the SD card, but as far as I can tell there's no way to do this. My options seem to be:
* Take the images out of the main app and make them a separate app that users would have to download. This is a terrible user experience.
* Take the images out of the main app and, the first time it's run, add logic for downloading the images and saving them to the SD card. This is what I'll have to do, I guess, but it's quite irritating to have to write and test all this extra code to work around limitations in the OS...

4 comments

Developing for webOS versus Android
Mood: determined
Posted on 2011-08-29 13:20:00
Tags: essay palmpre projects programming android
Words: 544

Over the weekend, I spent some time working on porting LJ for WebOS to Enyo, and after I got stuck there, I worked on porting FlightPredictor to Android. Since I was developing in both environments, I thought I'd give some more thoughts on Android (here's part 1):

I'm definitely learning more as I go, but there are still some areas (well, most areas) that developing for webOS is way easier than Android. I admit I'm biased in the matter since I've done a ton of webOS development, but sheesh:
- The Eclipse I'm using is decent in some ways and really frustrating in others. (I'm using MOTODEV Studio, because...well, I had an email from them and I just picked something) Keep in mind I'm used to developing in a text editor so the bar's pretty low here. It took me a while to realize that when you start debugging something you then have to switch to the "Debug" perspective to actually see what's going on. And 90% of the time when the app crashes, the only info I can see is that a RuntimeException was thrown, somewhere. (even when it's something easy, like a NullPointerException in my code!) Worse is when none of my code is on the call stack and I don't have the Android source code, so it gives me very little idea of where to start looking.

Honestly, the Intellisense is nice, but it just doesn't feel quite right, and often gets in my way. Hopefully as I get used to it I'll stop fighting with it so much. And the emulator is slow - it takes 15-20 seconds to get from pressing "Debug" to the app actually starting, and given the limited information I get back from the debugger it's almost not worth doing. (although if I know where the problem is, I can set breakpoints, etc., which is nice)

- To include a big list of structured data (i.e. a list of airlines), for webOS I just have to include a simple .js file assigning a big JSON array to a variable. For Android I have to generate an XML file (or a JSON file, I guess? Didn't try that...), and write initialization code to parse the XML file and store it.

- In webOS, doing an asynchronous web request is drop-dead simple - just use an XmlHttpRequest! Yay! In Android you have to spin up a new thread and post messages back and forth and such. Just reading that section of the book I'm borrowing depressed me, and I'm sure when I get to that it will suck.

- I wanted to have a Spinner (a list selector) that displayed a string and would return the associated value if it was selected. You know, like EVERY LIST SELECTOR EVER. Except, no - you can easily display a Spinner with a list of strings, but if you want to do something crazy like associate a value with it, you have to implement some interface and things generally get more complicated. What's so hard about a freaking templatized value type?? This makes me angry.

Anyway, nothing so terrible that I'm giving up, but a lot of annoyances and I really have to be in a tolerant frame of mind or I will start throwing things and cursing.

2 comments

trying to learn Android and missing webOS
Mood: angry
Posted on 2011-08-22 21:53:00
Tags: rant essay programming android
Words: 596

So, here's my plan: try to port FlightPredictor to Android and Windows Phone 7. Hopefully this will lead me toward which platform I'd rather own. Note: I am definitely not abandoning webOS, but I need a new phone and since the Pre3 is only being released in Europe and the European Pre3's will work on AT&T or T-Mobile but won't get 3G service, that's not gonna work.

So! First up is Android, mostly because I can develop for it on Linux. But it's not off to a good start. I'm reading through the mounds of documentation and not getting much of anywhere.

The very first screen in FlightPredictor shows a list of flights with their status and such. So I need to define a list in the UI and each list item I want to display certain properties of the Flight object.

In Enyo (the newest webOS framework), this is pretty easy. My list item code looks like:

{kind: 'HFlexBox', name: 'downTarget', components: [
{kind: 'VFlexBox', components: [
{kind: 'HFlexBox', className: 'flightsList info', components: [
{name: 'flightAirlineNameAndNum', allowHtml: true, content: ''},
{name: 'flightSummary', allowHtml: true, className: 'summary', content: ''},
]},
{kind: 'HFlexBox', name: 'cities', className: 'flightsList cities', components: [
{name: 'flightOriginCity', allowHtml: true, content: ''},
{allowHtml: true, content: ' to '},
{name: 'flightDestinationCity', allowHtml: true, content: ''},
]},
{kind: 'HFlexBox', name: 'times', className: 'flightsList cities', components: [
{name: 'departureTime', allowHtml: true, content: ''},
{allowHtml: true, content: ' - '},
{name: 'arrivalTime', allowHtml: true, content: ''},
]},
]},
...
and so on, and the code to display it looks something like:
    this.$.flightAirlineNameAndNum.setContent(flight.airline.name + ' ' + flight.num + ' ');
if (flight.category == FlightPredictor.FlightCategories.Current) {
this.$.flightSummary.setContent(flight.summary);
this.$.flightSummary.setClassName('summary ' + flight.summaryClass);
}
if (this.showCities && flight.category == FlightPredictor.FlightCategories.Current) {
this.$.cities.setShowing(true);
this.$.flightOriginCity.setContent(flight.originAirport.city);
this.$.flightDestinationCity.setContent(flight.destinationAirport.city);
} else {
this.$.cities.setShowing(false);
}
...
and so forth.

So, I thought a good first step for tonight would be getting something like this to work in Android.

First of all, the tutorial for ListView seems to assume that you want the list to take up the whole screen. (I want buttons at the bottom for adding a new flight, etc.) Digging around a little more, I found a page that says how to make the list coexist with other controls, and it says to do so I just make a ListView with id "@android:id/list". This is already a bad sign: what if I (gasp!) want two lists in a screen?

But, OK, I'll use your magic id. Some ids look like "@android:id/list" and the rest look like "@+id/flightsHeader" when I'm defining them and "@id/flightsHeader" when I'm referring to them. (why? I have no idea)

So then I have to define my Flight class, with annoying getters and setters that aren't necessary in JavaScript. After another hour of searching and getting frustrated, do I use the ArrayAdapter or a SimpleAdapter? (I'm just trying to define my flights in code - storing them in a database or whatever is for another day) ArrayAdapter lets me pass in an array of them, which I need, but it doesn't let me map the object fields to id's in the list template like SimpleAdapter does. But SimpleAdapter seems to only work on XML objects, or something?

Lists are important. I'm frustrated that the ListView tutorial is so drop-dead simple that it only touches the very simplest use case for a list (yay, a list of strings!) It looks like what I want is something like this list example except
- that's an awful lot of code
- it still doesn't show me how to set values into things in a resource file, which is supposed to be how all non-trivial views are done! Arrrrrrrrgh.

Anyway. Not a productive night. I want to stick it out and accomplish something before giving up, because that seems like the right thing to do, right?

4 comments

This backup was done by LJBackup.