Showing posts with label app. Show all posts

Hello Facebook..

I have been away on a mini-break for the last few days, and whilst relaxing I was mentally planning out a blog post about mobile phones as identity and the social platform they provide (again!), then, I woke up this morning to Facebook's announcement of their Hello app.  In short the app will attach FB user details to phone numbers, so if you get a call from a mobile number you don't know, but have the app installed on your phone, it will attempt display FB info to identify the caller.




For my money, this is a very smart move.


Moving down the stack

One of the questions for the future mobile landscape is whether players like Facebook and Amazon can move "further down the stack" - that is, to start being more core to devices, or making their own. Amazon have tried with their Kindle Fire phone, and Facebook had Home - both bombed out, however, and there hasn't been much to suggest that there is more promise for them.

However, Hello seems to me like it could be a small step to bridging that gap.  The app is simple in itself, and done well I could see it being very popular - after installing, it doesn't need any active engagement from the user, but (hopefully - without having tried it myself) just sits there and enhances the users phone experience (as long as they don't try and do anything stupid, crazy annoying notifications, battery hogging etc) - As a simple enhancement to the incoming call screen, I can imagine pretty high retention/install rate - because why would you go back to unknown numbers?

One reason this could be a huge win for Facebook is that this step could make Facebook more core to the mobile device (and seemingly appear more and more like just part of the OS).  If you have the app installed, and miss a call, I would expect the missed call notification screen to be Facebook's Hello - with the normal stuff you would expect - so and so called you, return call, send message etc - which will inevitably give FB the hook to drive users to FB messenger, WhatsApp etc - This is a chance for FB to hijack the core functionality of the phone and drive traffic to its other properties, quickly FB messenger could become the default messaging app.



Your phone as your identity & network

This is something that I have ranted about before - there are two powerful and fairly unique traits of mobile phones that have the power to really disrupt the social/technology/online space:

Your phone is your identity - Whilst people continue to struggle to fix online identification/authentication issues, with a host of different providers offering Login-as-a-Service (Twitter, Facebook etc) and lots of people complaining about the proliferation of user logins/passwords that need to be remembered, the phone offers an interesting solution to that - Granted, phone numbers are not for life, but they offer simple, unique identification of individuals, plus, with two-factor authentication, it can be simple to verify that the person attempting to login is in physical possession of the device.  And with more moves to ApplePay and NFC payment with your device, this identity/device becomes even more tightly coupled.  

By Facebook tying your phone number with your profile it is an impressive move to help future proof their platform: so your phone is your identity? Well now your FB profile is intrinsically linked to that too.


Your phone as a social network - For a long time, Facebook have been the dominant force in social networking. Despite Google's effort with Google+, they haven't been able to displace the social network king. Do you think they struggled because they couldn't match Facebook's superior product? You think people stay at Facebook because they just love the features so much? Of course not. They stay because of user inertia - the feature that keeps users at Facebook is the network effect, no one would move to Google+ without the rest of the network, and how to you move your network?  As if to prove this, there are fairly regular outcries from the Facebook masses when FB changes their layout, or people find out about some terrible clause in the privacy policy - but do people leave? Nope. They just get on with it and keep using Facebook.  After all, the users are the real product, not the software.

Now, mobile phones change that a bit.  Traditional online social-networking basically just models the real world network of friends/colleagues/etc - In your real life social network, you are the node in the graph, and your mobile phone basically represents your node - If you think of Facebook as a centralised social network, mobile phones are a distributed social network (in other words, Facebook knows about the entire graph, and keeps that information centralised, but with your phone you know about your immediate neighbours in the graph - e.g. the people you have contact details for, but not the rest of the graph).  This is a pretty powerful idea - and this is what has made it possible for apps like SnapChat and WhatsApp to enjoy sudden and un-precedented user growth where non-mobile only apps (Google+) haven't.

If we add to that the fact that modern smart phones aren't just an address book - they have your photos, they have your videos, they have your messaging, they have your friends - is there much on your Facebook profile that you don't have (the ability) to have locally on your mobile phone?

All of this makes the smart phone and the real world mobile connections a very powerful platform for anyone to come and disrupt Facebook's crown - So this move by Facebook again just helps establish them as leading the mobile-social platform, not just an old internet company trying to compete.



An aside - Google needs to catch up

My original thinking for the blog was going to be about how Google should, in my opinion, be capitalising on the Android platform as a social network, and rather than trying to convince users to sign up to Google+ (or Wave, or Buzz etc) focus their efforts on making Android a more social OS and make more of the Android as your identity.  They would have to do it carefully with regards to stuff like "private by default" so not to cause uproar, but if they could effectively make all their Android users a node in the social network, then all of a sudden they could find themselves with a pretty good social network, and can start thinking about how to add value to the product.  Furthermore, with Android being the OS (as low down the stack as possible) then they would have a lot more options with regards bringing together all the aspects above - Your smart phone knows instantly when you take a photo or record a video (because you are doing it with the device!), it knows your location, it knows when/who you are messaging, it knows who your friends are - some nice usability around that and it starts to sound like a very strong value proposition!

Christmas Sandwiches & an Android app


Following some banter on Twitter last week about christmas sandwiches (we have something of a tradition of eating, reviewing and ranking as many christmas sandwiches as we can find in the build up to christmas), I set a goal of creating a mobile app to help with this before the end of the week.

So, over the course of three nights (mostly commuting time) I built and launched a Christmas Sandwich rating app.  The app is basic. It let's people review sandwiches, and then read other people's reviews of sandwiches and see average ratings given to each sandwich.



It is an Android app that uses parse.com as the cloud backend to allow users to view other users reviews. At some point in the future, when I get the chance, I will put the code on github and write another post about what is going on, but in the meantime..

Get the app on the Play store

Enjoy!





Building a Twitter style autocomplete for Android

I have recently been working on an android app and found myself needing a Twitter style input box that allowed certain words to be looked up using an API driven autocomplete but also supporting freetext (if you have used the compose tweet input on android, like this - free text, but if you type @ then you get a user name autocomplete).



I google'd for a while, and stumbled through a few StackOverflow answers but none of there were 100% clear, and further more, just copy-pasting the code into a dummy project I was working in didn't work. So here is a break down of the what and how this works.

There are four main components:

The XML Layout: MultiAutoCompleteTextView


This is simple - just add the MultiAutoCompleteTextView just like you would any input. The only point of interest here is the "completionThreshold" - this is just the number of characters that have to be typed before auto-complete kicks in. We have set this to one char so it kicks in early.


We then just setup the auto-complete in our Activity onCreate

SetTokeniser: UsernameTokenizer

This is a custom class that implements the Tokenizer interface. This will be used by our autocomplete imput box to work out whether or not it should be displaying a dropdown menu. If you are using a static list for lookups (countries, fixed codes from your app, etc) then this is the only thing you really need to do - then you can just set the fields ArrayAdapter as the list of Strings etc and it will automatically kick in.

In our case, we are using the @ character to identify the start of pieces of text that should be lookedup and spaces to determine the end of the look up token.


The three methods are relatively straight forward - and will drive when your app presents the drop down:
  • terminateToken(CharSequence text) - this basically just provides a presentable version of our token with a proper terminator at the end (e.g. makes sure a trailing single space in this case)
  • findTokenStart(CharSequence text, int cursor) - Just finds the position of the start of the token. It does this by iterating backwards through the provided CharSequence (the text input in the input box) starting from the position of the cursor, which is just the position of the last character edited (this means if you go back and edit text in the middle of a block it still finds the correct token).  If no valid token start is found (e.g. we go backwards and we can't find a @ character) then the current position is returned - no dropdown is displayed.
  • findTokenEnd(CharSequence text, int cursor) - As above, but finds the end position. Iterates forward until a token terminator (in our case a space) or the end of the text is found

As long as you implement these to support your token identification pattern then you will get a dropdown appearing appropriately.


Adding a text changed listener

For ease of use on this one, I have just set the activity to implement the TextWatcher interface - the reason for this is just convenience - the implementation is going to handle calling our API asyncronously, so it is easier if it has the activity context.

There are three methods that need to be implemented - four our case there will be two no-op methods and just one implementation:


The method onTextChanged is implemented - unfortunately the tokenizer will only indicate to the application when to display the dropdown - it doesn't actually call the API, so we have to slightly repeat ourselves here in handling the API invocation.  In this method we need to again check for and find the relevant valid token in the input, and if a valid token found, then pass it to our API to lookup the dataset.

To help with that, I also added some additional methods to help check for the existence of a valid token (reading them should be self explanatory, but comments included inline)


In this case, as it was just an experiment, and I didn't actually have a user lookup API I have just used the LinkedIn skills API (this code also taken in part from a StackOverflow answer).

The Async task should also be straight forward, and can be implemented in whatever pattern you are using for Async calls - but the key point to note is how we are updating our dropdown list.


The API driven, multi-autocomplete/free text field should then be working as expected



Coming Soon..




New mobile-first product currently underway..

Flat Design (& Android)

"Flat" is currently a big design trend, with pretty much all the big players getting involved.  One of the earliest big-hitters in the field was an iOS app called LetterPress (incidentally, the designer behind this has recently been working on Facebook's "Paper" app - which is also a pretty nice experience)

http://www.atebits.com/letterpress/

The trend found a surprising champion in Microsoft with their Windows Metro look (Windows 8, Windows mobile, xbox), before Apple(iOS 7) later joined the party as Jonny Ives took responsibility for software design as well as hardware. Now many of the most popular sites are sporting a flat look (Google flattened its logo, twitter went flat, even NerdAbility.com is sporting a flat design).

Flat design is about being more minimalist and user-focused - it skips the fanfare of effects or lifelike details for apps/backgrounds/controls and favours simple, clean, crisp minimal interfaces. It's kind of the opposite to the skeumorphic approach - which is using lifelike textures/look&feels for things (the obvious examples being on iOS pre-7 where the contacts have graphics in the background that make it look like a leather address book, or the notes app that has a lined paper background etc).  It avoids fancy 3-d fonts and elements, avoids shading, shadowing, textures - and just uses simple colours, fonts, shapes to quickly convey meaning (see letterpress image above - no fancy rounded corners, fonts or textures - just simple block colours).


Flat Android Design

There is no reason why you can't design an Android app following flat trend, in fact lots already have - Thankfully, as a core part of the flat trend is simple, it is simple to build flat looking apps in no time at all.

Fonts

There isn't any hard and fast rule on fonts really - obviously it should be simple, clean and understandable - for this reason, clean, light san serif fonts have been a common font style to use. The most famous, as used by Microsoft, is Open-Sans - this is the font used across their Windows8 OS. It's popularity also boosted by the fact that it is freely available on Google Fonts, so has swept the web in a fairly big way.



Thankfully, as it happens, Android (since 3.0) has come with packaged with a lovely san-serif font called Roboto. The range of weights, especially the thin and bolder weights allow you to achieve similar aesthetics in line with common flat design, whilst presenting a professional, clean & simple typography.  The obvious disadvantage of using the font is as it's built into later Androids, it's fairly widely used.  Personally, I like to use it. I use the default Android font largely across my apps, and if I want to add a bit of character to a heading/title then I opt for the thinner version of the font.


Buttons

Buttons are an interesting one.  Whilst the flat trend is becoming more pervasive, there are still questions regarding buttons. Buttons have always been skeuomorphic by design - the shading and texture to show a raised/bevelled button (like a real life button that you might press) is classic skeumorphism, and whilst this is simple to switch to a 2-D, flat look&feel, there are still arguments as to whether you should do this - as the button look and feel communicates to the user that it is a button - it is so widely accepted a metaphor, people seem concerned that without the detail, people may not understand it is a button. How can they tell if something is a button or just a coloured block quote? (see this stackexchange question on the topic)

http://www.nngroup.com/articles/windows-8-disappointing-usability/

 Above is an example from Windows 8 controls - as pointed out on the StackExchange link, all of those icons are actually buttons, along with the "Change PC Settings" - That could be fairly confusing, and would be an example of how not to design flat buttons.

Personally, I like flat buttons - as long as you take care to design the page so that the buttons are clear, and the form/page obeys general good UI heirarchy - an example of a simple form I was creating for an app with simple flat buttons is below:


As you can see, designing forms/controls that obey standard UI heirarchy and normal metaphors then it is still incredibly simple and clear what are buttons are what aren't. (I know it doesn't look like a fancy form - there are other decorations elsewhere as well though!)


Colours

There are of course, no rules about colour - but there are trends. A simple google image search for flat colours will give you lots of palettes, and there are also lots of great free tools on the web for building palettes

http://mikehince.com/design/amazing-colour-resources-for-designers/


Adobe's Kuler being a great example (lets you build schemes as well as share them with the community and look at other schemes)



Android ORM - GreenDAO - Simplifying DB access in your app

I am currently working on a new Android app, and as usual, it requires a considerable amount of DB interaction.  I would say DB interaction isn't that difficult in Android - you can create a few simple classes to setup your schema and then DAO functions for the various domain objects that you want to map to the DB.

Simple.

Just a pain in the ass.

Coming from working on a variety of Java type ORMs (Hibernate et al), this is really just all boiler plate that is painful to write, so this time around I decided to look for an Android ORM. The first result in google was greenDAO, which claims to be being used on over 10million installed apps (AppBrain lists it as being used on Pinterest and Zynga apps), which seemed like pretty good reason to take a look.


So I started taking a look at the code on GitHub - the first thing I noticed was that it wasn't a traditional ORM that I expected, really it's more of a code generator rather than an ORM like Hibernate - I was expecting to just define some POJO entities, maybe marked up with annotations or config  that did all the magic - but what is actually going on is you have to create a "generator" project that defines your domain entities and then that produces several DAO and domain object classes that can be generated directly into your normal Android app.

Does generated code always suck?

I saw the words generator and alarm bells started to ring - I have worked with and on projects that generate code and it so often seems to have descended in to pain - often needing to slightly tweak the generated code, which then results in painful re-generation or just walking away from the generator altogether and being left with having to manually maintain generated code.

However, I had a look at the generated code and it was actually quite nice - not that different from if I had written it, and what swung it for me was the performance. I had briefly pondered building a lightweight ORM for Android more in the style of Hibernate (I love an annotation), but then I thought on the performance impact - reading annotations on POJOs at runtime - even if cached - the performance footprint was likely to be pretty big would suck for people with older/less powerful devices.


So actually, removing the pain of having to create all the DAO objects etc, whilst not having a prohibitive performance impact made this a pretty strong choice.


Let's get down to business, don't got no time to play around, what is this..

So lets have a look at how we generate the code - its actually relatively easily to programmatic-ly configure your entities for generation.





The above is an example of how you can configure two simple domain entities (which will map to a table - this is like defining a Hibernate @Entity POJO). In the above simplified, hypothetical design, we have two real domain entities "Email" and "People" - emails can be sent to multiple people, and people can recieve multiple emails.

As you can see, we define a very simple People entity. and then programatically add three columns - an ID, a name and an email address. Simple - and as you can see(or imagine) the API provides programatic constructs to configure not null, column types, etc.


All in all, so far it has been a good experience - It has removed a certain amount of the pain from developing the DAO/DB layer boiler plate stuff and let me concentrate on the important stuff about the app. However, one gripe I do have is that it doesn't currently support modelling of many-to-many relationships - the best you can do is create an entity to model what is effectively a join table, then have a one-to-many relationship from that to either side of your "real" many-to-many relationship.

Again, in the above example, we try manage the many-to-many relationship between people and emails (emails can have may people recipients, and people can be recipients to many emails). As mentioned - we have had to model this join explicitly with an EmailPeople entity, and then add the OneToMany relationship between People/Email to our new Join entity.  This is no real headache to do, but is undoubtedly going to be a performance hit - The underlying code will undoubtedly be being cleverly efficient in retrieving all the EmailPeople entities for a given email (assuming attempting to get all recipients to an email) - but from that list we then need an efficient way to load all the People enties linked to that list of EmailPeople entites.
 

Retiring my Apps (website)

I have decided this weekend to retire my Android app development website (if you haven't already checked it out, you can still find it here for a while). The site was only really to provide more information and a contact method for anyone interested in the apps (and as part of an online portfolio really) but as my focus has been on other things (amongst them being Flutterby) I decided it was time to retire the site.

The apps will still be available of course, from the Android market, and I also updated my photo FX app "The Cutting Room" to be free now (as well as previously open sourcing the Android image processing libraries).


Getting Started - A Complete Android App walkthrough for Beginners (Part 2)

This is part 2 of a walkthrough of one of my first ever Android app, that happened to get a little bit of love in the android market, and for which the ENTIRE(!!) source code of the application is available to you good people to do whatever you want with.. see part 1 for more details of the app, what happened and the first steps in getting started!

So far, we have created a simple Activity class, designed a layout with several buttons and then implemented an onClickListener within our Activity class to handle the required actions for all of our buttons. The remaining Activities are all fairly straight forward, and work in a similar fashion: the RulesActivity is just a simple activity what has a block of text with a brief description of the game; the SettingsActivity is a simple activity that has three radio buttons which allows the user to select the difficulty; the QuestionsActivity just displays a question and then a selection of multiple choice answers.

If you are not familiar with Activities then you can open up those other classes and see exactly what is going on, they are all pretty similar but each have slight nuances or differences in their components and actions.

At the moment the application is pretty simple – there is a basic welcome screen with some buttons, and once you start the game you get taken through the QuestionsActivity several times, refreshing with different questions until you have answered all the questions, and then at the end it displays a simple graphic based on your accumulated score. Easy right?!

Really, the only big gap in what is going on is the DB – all the questions need to be stored in the DB on the client device, and then that data needs to be accessed, so we basically need a DAO type class.

In this app, we have a single DBHelper class – you may want to wrap this with a service class, to allow better separation of layers and decreased coupling etc, but for the sake of this app, lets just jump into the DBHelper. To access the DB on Android you need to have your class extend SQLLiteOpenHelper, now lets walk through the code required

private static String DB_PATH = "/data/data/com.tmm.android.chuck/databases/";
private static String DB_NAME = "questionsDb";
private SQLiteDatabase myDataBase; 
private final Context myContext;

First of all we define some simple class member variables. The DB_PATH will be used later to access our file that contains all our questions in it, the DB_NAME is just a name of choice to reference the DB.

public DBHelper(Context context) {
 super(context, DB_NAME, null, 1);
 this.myContext = context;
} 

You have to make sure you override the constructor, as this needs to initialise the context and DB before starting.

Next we have the createDatabase method – this one is quite straight forward:

public void createDataBase() throws IOException{

 boolean dbExist = checkDataBase();
 if(!dbExist)
 {
  this.getReadableDatabase();
  try {
   copyDataBase(); 
  } catch (IOException e) {
   throw new Error("Error copying database");
  }
 }
}


As you can see, it simply checks if the DB already exists, if it doesn’t (in which case its the first time that the app has been launched on this device) then it calls the copyDataBase() method:

private void copyDataBase() throws IOException{

 InputStream myInput = myContext.getAssets().open(DB_NAME);

 String outFileName = DB_PATH + DB_NAME;

 OutputStream myOutput = new FileOutputStream(outFileName);

 byte[] buffer = new byte[1024];
 int length;
 while ((length = myInput.read(buffer))>0){
  myOutput.write(buffer, 0, length);
 }

 //Close the streams
 myOutput.flush();
 myOutput.close();
 myInput.close();
}

Again, this is pretty straight forward – it just opens an Input stream to read the file (our questions file that we have saved in the /assets/ directory) and then writes it to the output stream which has been set up to be our DB Path/Name. Easy right?

So now we pretty much have our DBHelper class that checks for an existing DB, if its found then it opens a connection, if its not then it loads the data (our question set) in for the first time.

Now, the only remaining thing that our helper needs to do is to be able to access the data so we can select questions to show the user. So let’s look at how we add some DAO access methods. What I have done here is create a simple method to return a (random) question set:

public List getQuestionSet(int difficulty, int numQ){
 List questionSet = new ArrayList();

Cursor c = myDataBase.rawQuery("SELECT * FROM QUESTIONS WHERE DIFFICULTY=" + difficulty +
   " ORDER BY RANDOM() LIMIT " + numQ, null);
 
while (c.moveToNext()){
  Question q = new Question();
  q.setQuestion(c.getString(1));
  q.setAnswer(c.getString(2));
  q.setOption1(c.getString(3));
  q.setOption2(c.getString(4));
  q.setOption3(c.getString(5));
  q.setRating(difficulty);
  questionSet.add(q);
 }
 return questionSet;
}

Here, I am modelling the questions in a pre-created “Question” class – this just has the necessary member variables so I can handle the questions more easily than having to try and deal with DB cursors throughout the code. In the above method we just call a pure SQL statement, and then iterate through the cursor to populate my Question ArrayList.

And thats it! There are some other Activity classes and helper classes running doing small things throughout the app, but the core features are covered, so feel free to have a look around the code, edit it, change the design and just generally have fun.

Getting Started - A Complete Android App walkthrough for Beginners (Part 1)

About a year ago I released my first app on to the Android market. I had developed the market primarily as a learning tool, and at the end decided that putting it on the market would be a good step to understand the process and get some feedback.
The application was a simple quiz app based on the popular NBC series Chuck, I released it for free (no-ads) and no real advertising other than one or two target tweets. The app currently has about 4,000 – 5,000 downloads with a 4 star rating – both of which it achieved pretty quickly in the first month or two.



DISCLAIMER: I believe this to be purely down to the fact that at the time there weren’t really any other Chuck related apps, and it has a nerd-ish, cult like following, so I think the rating and popularity is more of a reflection on the show’s popularity than the quality of the app!


Anyway, I thought it might be interesting/helpful to release the source code here and walkthrough the different aspects of the code in a tutorial “my first app” kind of way.

I won’t go in to the setting up Eclipse/Android plug-ins stuff here, so will assume familiarity with getting around the IDE.


Android Directory Structure
Creating a new Android project in Eclipse (using the Android plug-ins) creates the required project structure automatically for you. Lets have a look at that now:


Src : as you would expect, this is the main java source directory, so this is where all your source code lives

Gen: this is the generated code that Eclipse handles for you – the files in here will be generated from your config. You needn’t really worry about what happens in here as Eclipse takes care of it for you

Assets: this can be used to contain any resources or libraries you want to bundle with the app – such as third party jars and data sets (you will see later we use this directory to store the data that we will load to populate all the questions in the DB when the app is first launched on a new device)

Res: this is where the configuration for the layout/UI aspects live:
- Drawable – keep you image files in here (.png/jpg/etc)
- Layout – this is where you keep the xml config for UI layout
- Values – this is where you keep the config with application code, such as application name or set text. This means you can easily change text through out the application without having to change hardcoded strings in the java code and re-compile


Getting Started
Ok, lets get started – the first thing we need is a welcome screen that is displayed when a user first launches the app. In Android, a screen is modelled by an “Activity” class, so to create our welcome screen we need to extend Activity.

public class SplashActivity extends Activity implements OnClickListener{

 @Override
 public void onCreate(Bundle savedInstanceState) {

Every class that overrides the Activity class must implement the onCreate() method – this is called when the activity is launched. As our welcome screen will just be a simple screen with a few buttons on it (play, rules, exit) we don’t need to do much at this point other than set up the buttons to have a listener so we know when one of them is pressed. For convenience here, we will set our current activity class to implement “OnClickListener” – this means we can define the onClick() method directly in our activity to handle the button events.

@Override
 public void onClick(View v) {
  Intent i; 
  switch (v.getId()){
  case R.id.playBtn :
   List questions = getQuestionSetFromDb();

   GamePlay c = new GamePlay();
   c.setQuestions(questions);
   c.setNumRounds(getNumQuestions());
   ((ChuckApplication)getApplication()).setCurrentGame(c);  

   //Start Game Now.. //
   i = new Intent(this, QuestionActivity.class);
   startActivityForResult(i, Constants.PLAYBUTTON);
   break;
   
  case R.id.rulesBtn :
   i = new Intent(this, RulesActivity.class);
   startActivityForResult(i, Constants.RULESBUTTON);
   break;
   
  case R.id.settingsBtn :
   i = new Intent(this, SettingsActivity.class);
   startActivityForResult(i, Constants.SETTINGSBUTTON);
   break;
   
  case R.id.exitBtn :
   finish();
   break;
  }
 }

As you can see, we have one single method that handles any button press, and we manage this with a switch statement checking the id of the view (we will go into this later). Mostly, the cases are simple, “exit” finishes the application whilst “rules” and “settings” have code like this:

i = new Intent(this, RulesActivity.class);
startActivityForResult(i, Constants.RULESBUTTON);

Intents are objects in Android that are used to communicate between activities, and as you can probably spot from the above, this simply creates a new Intent and then uses it to start another Activity class, in this case, our RulesActivity class.

The “Play” case is slightly more complicated – as this needs to initialise the game and load the questions to be used from the DB. Once it has done this, it loads the information in to our “Application” class (we will cover this later also) and then just kicks of the QuestionsActivity with a new Intent as per above.

So that is our welcome page pretty much done, we have a single screen that has a few buttons and we have setup listeners to perform appropriate actions on pressing them. The only remaining issue is the layout of the screen.


Activity Design

In the onCreate() method of our Activity you will notice the second line is

setContentView(R.layout.welcome);

This call tells Android which layout xml file should be used to configure the design – to find the relevant file is quite intuitive, its simply going to be located at /layout/welcome.xml



There are several layouts available to use, each of which are applicable in different circumstances, but as we are just going to have a straight list of buttons, we will use the simple “LinearLayout”. You can nest layouts, as you will see in this example, but lets walk through some of the config options we are using for our layout:

android:orientation="vertical" – This defines our layout as vertical, so new elements will be added on a new row below (if it were horizontal it would add as a new column)

android:layout_width="fill_parent" – this tells the activity to fill the whole width of the screen with the contents

android:layout_height="fill_parent" – this tells the activity to fill the whole width of the screen with the contents

android:gravity="center_horizontal" – this centers all elements that are contained in this layout

android:background="@drawable/background – this defines a background image to use for the activity (this image should exist at /drawable/background.png)


Now, if we look inside the layout you will see some simple components. The first one being a simple ImageView, which points to an image that we want to use as a header. The following elements are the buttons – you will notice that the ID of each button corresponds to the onCreate() method of our Activity where we inflate the button to set the onClickListener.
If you press the “Graphical Layout” tab in eclipse, you will see what the welcome screen will look like.




Ok, so we have our welcome Activty, we have designed a nice UI to control the app and have an onClick handler - the next part will cover intergrating with the DB to pull out the questions and then we are all there!


Grab complete source code for the project here