Mark Lapasa

This is a great walkthrough/preview on developing for Glass. It confirms that there is very little to no Android so it’s a brand new platform. Originally I was excited about this but after looking how simple the API is, Glass seems fairly rudimentary. My main complaint is how strongly tied it is to Mother Google. As a third party developer, we have to have all calls route to Google via a REST interface. All Glass devices gets all of it’s presentation tier prepared by Google’s server-side.

Last year, I wrote an internal PDF document describing what steps it would take to get an Intel Gingerbread virtual device up and running. To my surprise, more people read it than I could have ever imagined. It benefited non developers like Customers, QA, Directors, and Engagement specialists. It also helped Non-Android Developers like server side devs who needed a client to test with as well as HTML5/JS devs who wanted to see what their pages would look like in a stock browser.

Initially I wrote the doc after the 10th request to set up the emulator on their local machines. Visually documenting saved me a lot more hours towards development and it didn’t take long to assemble it either.

The honeymoon ended when the user interface changed on the AVD Manager. New users found the document less helpful because it didn’t correspond to what needed to be done. The document became obsolete when the screenshots of the old developers.android.com website got a nice make over and links changed locations on the site. I have since drafted together an updated visual guide to reflect recent changes.

Instead of updating the word document and exporting a PDF, I’ve opted to go with a publicly available Google Presentation so that it be both easily changed and easily shared. G-Presentations lend themselves to landscape views verses Google Doc’s Portrait. I’ve now learned PDF’s are not good for living documents.

If you are an Android developer who works with the audiences described above, you probably have run into the same scenario. Share this Google Presentation with your colleagues who need to get a Jellybean Android Virtual Device up and running on their machine.

Today, I was a lucky enough to be a part of series of speakers discussing how Cloud Technology and Open Data initiatives can make an impact on E-Healthcare. I gave a very quick 10-minute overview of mobility, cloud and how to tie it together using Google Cloud Endpoints.

You can view the slides from here or on Google Docs.

To view speaker notes, go to the Cog symbol -> Select Open Speaker Notes

You no longer have to be a registered member of the Trusted Tester program. It’ll be interesting to see in the coming months if the mobile community in general will adopt Endpoints and App Engine for their backend needs. From my experience, making REST API’s for any consumer could not be made any more easier.

Here’s the latest news in case you were not a member of the Trusted Tester program:

Hello testers,

As of the App Engine 1.7.5 release on Wednesday afternoon, Google Cloud Endpoints has graduated from Trusted Tester, and is now considered a public, “Experimental” feature.

The 1.7.5 release contains updated Endpoints code for both Java and Python. In addition, we now have public documentation for both Java and Python, which you should now refer to for future development. These docs are a direct superset of the TT documentation.

We will be winding down the TT program over the next week. Questions relating to Endpoints development should now be directed to the google-cloud-endpoints tag on Stack Overflow. Next week, we will mark this forum as read-only. Feel free to continue ongoing discussions on the list in the interim.

On behalf of the engineering team, I’d like to extend a big “Thank You” to all the testers. The feedback from all of you has been incredibly helpful during the development of Endpoints.

Thanks,
Dan

–
Dan Holevoet
Google Developer Relations

Here’s some resources to get you started:

Presentation:
http://bit.ly/endpointsGTUG

Video:
http://youtu.be/iKoOyaF65I4

FAQ/Q&A:
http://knowledge.lapasa.net/?p=893

Owned 1-to-1 Relationships

An Employee ‘has a’ ContactInfo

//////////////////////
// ContactInfo.java //
//////////////////////
import com.google.appengine.api.datastore.Key;
// ... imports ...

@PersistenceCapable
public class ContactInfo {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private String streetAddress;

    // ...
}

///////////////////
// Employee.java //
///////////////////
import ContactInfo;
// ... imports ...

@PersistenceCapable
public class Employee {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private ContactInfo contactInfo;

    ContactInfo getContactInfo() {
        return contactInfo;
    }
    void setContactInfo(ContactInfo contactInfo) {
        this.contactInfo = contactInfo;
    }

    // ...
}

To declare a 1-to-1 bidirectional relationship, use @Persistent(mappedBy = “{kind}”)

//////////////////////
// ContactInfo.java //
//////////////////////
import Employee;

// ...
    @Persistent(mappedBy = "contactInfo")
    private Employee employee;

To add the child field to the default fetch groups so that the child is retrieved and loaded with the parent, use defaultFetchGroup=”true”

///////////////////
// Employee.java //
///////////////////
import ContactInfo;

// ...
    @Persistent(defaultFetchGroup = "true")
    private ContactInfo contactInfo;

Owned 1-to-many Relationships

Use a Collection class

///////////////////
// Employee.java //
///////////////////
import java.util.List;

    // ...
    @Persistent
    private List<ContactInfo> contactInfoSets;

An example of 1-to-many bidirectional that uses the @Persistent(mappedBy = “{kind}”) annotation

///////////////////
// Employee.java //
///////////////////
import java.util.List;

    // ...
    @Persistent(mappedBy = "employee")
    private List<ContactInfo> contactInfoSets;

// ContactInfo.java
import Employee;

    // ...
    @Persistent
    private Employee employee;

Un-owned 1-to-many Relationship

Use the @Unowned annotation to setup an unowned 1-to-1 relationship

/////////////////
// Person.java //
/////////////////
// ... imports ...
@PersistenceCapable
public class Person 
{
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    @Unowned
    private Food favoriteFood;

    // ...
}

///////////////
// Food.java //
///////////////
import Person;
// ... imports ...
@PersistenceCapable
public class Food {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    // ...
}

Un-owned 1-to-many Relationship

/////////////////
// Person.java //
/////////////////
@PersistenceCapable
public class Person 
{
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private Set<Food> favoriteFoods;

    // ...
}

Many-to-Many Relationships

You must maintain collection of keys on both sides

/////////////////
// Person.java //
/////////////////
import java.util.Set;
import com.google.appengine.api.datastore.Key;

    // ...
    @Persistent
    private Set<Key> favoriteFoods;

///////////////
// Food.java //
///////////////
import java.util.Set;
import com.google.appengine.api.datastore.Key;

    // ...
    @Persistent
    private Set<Key> foodFans;

////////////////
// Album.java //
////////////////
// ...
public void addFavoriteFood(Food food) {
    favoriteFoods.add(food.getKey());
    food.getFoodFans().add(getKey());
}

public void removeFavoriteFood(Food food) {
    favoriteFoods.remove(food.getKey());
    food.getFoodFans().remove(getKey());
}

Relationships, Entity Groups, and Transactions

Employee e = new Employee();
ContactInfo ci = new ContactInfo();
e.setContactInfo(ci); // Create association

// Persist the association atomically. If GAE cannot guarantee 
// the parent cannot be made before the child, it will 
// abandon it's work and roll back to the original state
try 
{
    Transaction tx = pm.currentTransaction();
    tx.begin(); // Declare the transaction with begin
    pm.makePersistent(e);
    tx.commit();
} 
finally 
{
    if (tx.isActive()) 
    {
        tx.rollback();
    }
}

Dependent Children and Cascading Deletes

Add ‘dependent’ flag to @Persistent to set up cascading delete for owned 1-to-1 relationship

@Persistent(dependent = "true")
private ContactInfo contactInfo;

Add @Element(dependent = “true”) to make owned 1-to-many relationship able to cascade delete

@Persistent
@Element(dependent = "true")
private List contactInfos;

Polymorphic Relationships

//////////////////////////////
// Recipe.java - Base Class //
//////////////////////////////
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.Inheritance;
import javax.jdo.annotations.InheritanceStrategy;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;

@PersistenceCapable
@Inheritance(strategy = InheritanceStrategy.SUBCLASS_TABLE)
public abstract class Recipe {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private int prepTime;
}

//////////////////////////////////
// Entree.java - Decedent class //
//////////////////////////////////

@PersistenceCapable
public class Entree extends Recipe {
// ... entree-specific fields
}


/////////////////////////////////////////////////////////////
// Chef.java - BROKEN This example of a Chef storing their //
// favorite recipe will not work because Entree entity is  //
// different type than the Recipe entity                   //
/////////////////////////////////////////////////////////////
@PersistenceCapable
public class Chef {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent(dependent = "true")
    private Recipe favoriteRecipe;
}

//////////////////////////////////////////////
// Chef.java - FIXED Use Key object instead // 
// which will not have type                 //
//////////////////////////////////////////////
@PersistenceCapable
public class Chef {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Key key;

    @Persistent
    private Key favoriteRecipe;
}

Source: https://developers.google.com/appengine/docs/java/datastore/jdo/relationships

Esc – Back Button
F2 – Menu Key
Home – Home Button
Ctrl+F11 – Landscape orientation
Alt+Enter – Toggle fullscreen mode, great for demos

The above are the ones I find myself doing most often when I have a skinless emulator which is the case when testing ldpi and mdpi.

If you want hdpi skins for older Nexus devices, go here:

http://heikobehrens.net/2011/03/15/android-skins/

For a long list of Android emulator shortcuts, check them out here:

http://www.shortcutworld.com/en/win/Android-Emulator.html

I don’t know why Dialog windows get a bad rep in Android. It might be because they can overly be abused. But sometimes you just need the modality that a dialog provides to get the job done. In Android, we populate the onCreateDialog(int) hook to return Dialog instances. What you may not know or care about is if you call this method with the same parameters, it will always send you back the same instance it created the first time around.

The base Activity class creates a private map using a SparseArray to keep a cache of dialogues. When the Activity gets destroyed, it will also destroy the cache.

The pros of this approach is that it is efficient in instantiating a Dialog only once.

The con is that if you want to show dynamic content in it, that data is baked into the one instance so that it is statically displayed every time it is recalled. To get around this, use onPrepareDialog(int id, Dialog dialog) which will be invoked every time and will provide you with the instance that is cached by the activity.

Alternately, you can use removeDialogue(int id) from the Activity to clear the instance from the Activity.

For Post-ICS developers, this approach is deprecated in favor of DialogFragments.

5) “It’s O.K. to screw up, I’ve been doing it for years!!!” – Chris Haseman (Tumblr)

After years of mobile software development, nobody ever gets it right the first time. Nobody will hit a home run the first time they are at the plate. Failure is not a destination. It’s a required function to figure out how to make it right. Rock that Flame-retardant jacket when reading your app’s painful reviews. 1-star with no comments means you made no impact that resonates with them. 1-star with comments means they care enough to say you suck. However, be very selective what costs are associated to user feature requests. I think Chris’ end keynote was something tangible everyone in our industry can relate to.

(However, I’ll have to argue with Chris that it is not OK to screw up when the money runs out. )

4) “Multi-Screen doesn’t have to be a TV paired with a device. It can also be device to device on the same Wi-Fi LAN” – Matthew Patience (Bnotions)

Cool proof of concept of how we developers can make multiple Android virtual machines to talk to each other. Google TV is a tough sell though. I like how TV set manufactures are making it a feature differentiator over their competitors. However, writing a Google TV app is as equally complicated as writing any other Android app. That said, it probably has by far the smallest audience in the ecosystem.

3) “Tapestry is a way to visualize a user’s line of thought” – James Wu (Kobo)

One of the best ways to take advantage of the large real estate of a tablet is not to fit more paragraphs of text but display a collection of thumbnails. Each thumbnail could represent 1000 words in the same space a 10-word TextView control takes up.

When tablets first came out, it was about deploying the phone version in a tablet which made it all stretched out and crappy. It really discounted the extra pixel space. This is not the original intention but because we didn’t know better. Google gave us the technical tools to do this with Fragments but it can be a difficult visual metaphor for a n00b trying to get their head wrapped around how Activities work. Tapestry is a great UI dialect that exploits the extra pixel space and gives us a visual metaphor that we can all relate with, that also exploits Fragments as well.

2) “Take the bytecode of AE and render it on the device” – Peter O’Bleins (Flick Software/Freakin’ Awesome Apps)

Very cool presentation about how Flick Software harnesses the power of After Effects and the cross mobile power of C++ to deliver high performance user experience on iOS and Android.

Pros:

• Take the bytecode of AE and render it on the device.
• Motion designers can work in a tool they are familiar with. The assets they generate can be made once and compile to many targets.
• In the right hands, this workflow can yield the most mind-blowing high performance non-native user experience HTML5′ers wishes they can do. It writes once but compiles everywhere and doesn’t run like crap
• Business logic is written once for all targets
• Presentation logic to trigger the timelines of each moving asset is written once for all targets

Cons:

• IMO, C++ is not as an accessible language to pick up as say Java. C++ is Latin as Java is to English.
• In order to support dynamic layouts, they must have had to re-write their own size, measure, and render layout engine when UIToolkit and Android Java Framework already do this pretty well
• For the budgets of many projects, sometimes all you need is a simple list. Not the sexiest one ever made.

The presentation was very reminiscent of how Flash made it’s way into our lives through desktop browsers. It broke the barriers HTML set up everywhere. The guys at Flick are performing a similar feat of getting timeline animations into our lives through cross-mobile native apps. It attempts to break the barriers HTML5 (performance) and native (platform lock-in) have set up.

1) “We Can Do Better” – Alan Paulin (Google)

Re-think App Initialization – I’ve been doing client-server for so long that configuration upon each and every login is trivial. Cloud to Device messaging has been around for a while. It never occurred to me that we can pre-fetch this step to reduce the penalty of initializing an application. Server-side push happens once and all the settings can be wrapped in that bundle and persisted on the device. The app reads from its cache instead of waiting to hear from the server after login. Absolutely brilliant.

Web-View Tricks – Once you’ve made the correct choice to go with WebViews, display the most static template-able aspects of the view the user ahead of a call. The call itself should be reduced to an AJAX request. The moral of the story is to get users to download just the data rather than data wrapped in visual layout markup.

Comments about the conference:

• It ended at 4pm. What the hell! Oh well, I’m alright with that because the after party started early. Maybe next year it will be renamed AndroidTO Happy Hour and it’s an actual slot on the schedule.
• Also because it ended early, it should start early. 8am Keynote. Maybe +5 minutes between sessions. Networking/Office Hours is as important as the sessions themselves
• Theatre + Location is a winner. Attendees will understand if conference starts at 8am because movies start playing at 4pm
• Give us back the panels!!! Give me conversation/controversy. Get those experts up on that stage.
• Your 4th year’s 4th track should be hardware focused/XDA focused. A lot of users want to know how to unlock the power of their device. Give XDA community, Bluetooth and USB Hackers a soapbox.
• Keep the prices low and I will keep supporting it

Android Asynchronous Http Client is a great tiny 25k jar to add to a project that requires Android clients to perform HTTP Request/Response transaction with the server side.

The interface is very clean and simple. It handles beefier use cases like uploading binary data like images and sets up hooks for parsing JSON response from the server-side.

It’s very basic and does the job.

You can check it out here -http://loopj.com/android-async-http/