Insider's Guide to Udacity Android Developer Nanodegree Part 7 - Full Stack Android
Written by Nikos Vaggalis   
Monday, 23 April 2018
Article Index
Insider's Guide to Udacity Android Developer Nanodegree Part 7 - Full Stack Android
Adapting to Android's Needs
HTTP Requests
Combating Memory Leaks
GSON Problems
Filtering and Comparing Devices
Functional Programming in Java
Conclusions

Yes, the final stage of the Capstone and graduation, the endless sense of relief. It was challenging, it was hard, but in the end everything worked out alright and I gained my Android Developer Nanodegree. So what did I think of the whole experience. If you just want to know my final thoughts on a year-long course of study turn to the last page.

At the final stage it wasn't just a Capstone project that spanned the narrow boundaries of developing for Android only. It also required work on the infrastructure as the Android app would have to communicate with the backend Digital Ocean VPS hosting the data.

So in this final part of the Insider's Guide To Udacity Android Developer Nanodegree  I'm not just going to go through the building of a mobile app, looking into the topics of Fragments, Loaders, AsyncTasks, Retrofit network calls, GSON parsing and Memory leaks, only. I'm also going to go through the work that took place server side, looking into Web based MVC, HTML template rendering, Perl coding, Data Modelling, functional programming in Java and so on.

But before getting into that, let's first have a refresher on what my app, conceived as part of the Capstone project, is about :

Capstone Project

Smart Device Seeker native app

 

Description

Contemplates the Smart Device Seeker proof of concept web site smadeseek.com by also offering a native mobile experience. The website aims to become a database for smart devices letting users to search for their ideal device (phone, tablet,smartwatch) by going through specialized criteria, such as the screen size of the device, the amount of megapixels the rear camera has, and so on.

 

Intended User

Any consumer interested in buying or looking for more information on a smart device.

App Features

  • Lists trending models of SmartPhones/Tablets/SmartWatches
  • Allows users to fine grain the device listing through filtering and searching capabilities
  • Displays detailed specifications and promo photos of the device
  • Allows users to favourite as well as compare devices

So although the backend infrastructure was in place, on parts such as the RDBMS (MySQL), Database Design, Server Side programming (Perl/Dancer framework), Application Server (Starman,Plack/PSGI), Web Server (Nginx) and Data Entry portal (custom CMS built with Xataface), let's call all of them collectively the Droplet, this setup was configured with delivering HTML in mind, catering for just one kind of client, the browser.

As such the Droplet was not equipped to expose an API endpoint that other kind of clients such an Android app could plug into, considering that throughout the course of the Nanodegree we've been always connecting our apps to backend RESTful APIs that talked JSON.Since smadeseek.com spoke HTML only, it had to be amended.

 

The user's flow and interaction with the WebSite

The way a visitor interacts with the WebSite is first by picking a category from between Phones, Tablets or Watches.That would redirect to the respective category URL

http://smadeseek.com/smartphones

or

http://smadeseek.com/smartwatches

or

http://smadeseek.com/tablets

as well as populate the JQuery enabled HTML based UI (Checkboxes, Sliders, Drop downs) with the chosen category's specifications data ranges.

So if the picked category was 'smartphones', the corresponding "Brands" drop down menu would be filled with the brand names available to phones only.Picking 'smartwatches' would bring up a different list of brand names available to watches only.The same holds true for the rest of the criteria too, so that for example the phones' Screen Size slider would be set to a greater range of values than the watches' equivalent.

 

Brands of phones

 

 

Brands of watches

The action of retrieving the appropriate data in order to populate the UI takes place inside the Model (the 'M' in MVC) which is forwarded the 'smartphones' keyword from the Controller (the 'C' in MVC) and uses it as an argument to the respective SQL queries:


sub get_tablets {
my $req=shift;
database->do("set session transaction isolation level
read committed"); #Fetch Brands data from database by calling the #'selectBrand' stored procedure my $sth = database->prepare(qq{CALL selectBrand(?)}); $sth->execute($req); while ( my $ref = $sth->fetchrow_hashref ) { if ( exists $brandhash{ $ref->{BrandName} } ) { push $brandhash{ $ref->{BrandName} }, { ModelId => $ref->{ModelId}, ModelName => $ref->{ModelName}, ModelVersion => $ref->{ModelVersion} }; } else { $brandhash{ $ref->{BrandName} } = [ { ModelId => $ref->{ModelId}, ModelName => $ref->{ModelName}, ModelVersion => $ref->{ModelVersion} } ]; } } #Add fetched data to the $hash_of_results Perl hashref
#data structure under key 'BrandHash' $hashOfResults{'Brandhash'} = \%brandhash; #Fetch OSList data by calling the #'selectOS' stored procedure my $sth = database->prepare(qq{CALL selectOS(?)}); $sth->execute($req); while ( my $ref = $sth->fetchrow_hashref ) { push @oslist, $ref; } $hashOfResults{'OSList'} = \@oslist; ... ... ... }

$hash_Of_Results acts as the container for the collected data and is passed back from the Model to the Controller.The Controller then feeds it to a TT (Template Toolkit) template, 'tablets.tt'.

 
my $template_data = { brandhash => $hashref->{'Brandhash'}, oslist => $hashref->{'OSList'}, cpuhash => $hashref->{'CPUhash'}, } return template 'tablets.tt' => $template_data;

Processing the template is the Viewer's ('V' in MVC) responsibility, who mixes the data with HTML, JQuery, CSS and TT's Perl alike language in order to generate the final HTML for the browser to render.That is a HTML page comprised of a left side menu which hosts the criteria you can filter the devices by, and on the right side, of a preview list of all the category's devices.

 

Left menu/Right device list

After that, the user is expected to filter through the device list by tweaking the menu's elements, like dragging the Screen Size, RAM, or Battery sliders, or picking a Brand or CPU from the drop down menus, and so on.Whenever an element of the left side menu is manipulated, an AJAX request is fired that collects every menu element's value and uses them to make an 'application/x-www-form-urlencoded' POST request towards

http://smadeseek.com/tablets1

offset=0&SortById=ModelName&radioSort=asc&CpuCores=
-1&ModelId=0&BrandName=Acer&CPUId=-1&CPUBrandAndType=
&OSId=-1&ScreenTypeId=-1 &ScreenResolutionId=-1&ScreenProtectionId=
-1&NetworkSimTypeId=-1&NetworkSimQuantityId=
-1&ConnectivityWifiId=-1&ConnectivityBluetoothId=-1 &ConnectivityUSBId=-1&CameraRearVideoResolutionId=
-1&RAM_from=0&RAM_to=512&StorageInternal_from=
4&StorageInternal_to=128&StorageExternal_from=32 &StorageExternal_to=256&Battery_from=2000&Battery_to
=6050&Antutu_from=0&Antutu_to=29856&ScreenSize_from=
3&ScreenSize_to=6 &DimensionsHeight_from=13&DimensionsHeight_to=
173&DimensionsWidth_from=6&DimensionsWidth_to=
154&DimensionsDepth_from=0 &DimensionsDepth_to=17&DimensionsWeight_from=
100&DimensionsWeight_to=210&DimensionsSurface_from=67& DimensionsSurface_to=70&NetworkSarUS_from=
0&NetworkSarUS_to=0&NetworkSarEU_from=
0&NetworkSarEU_to=
0&CameraFrontResolution_from=1 &CameraFrontResolution_to=23&CameraRearResolution_from=
1&CameraRearResolution_to=21&BatteryRemovable=false

which the server side parses as

offset=0
SortById=ModelName
radioSort=asc
CpuCores=-1
ModelId=0
BrandName=Acer
CPUId=-1
CPUBrandAndType=
OSId=-1
ScreenTypeId=-1
ScreenResolutionId=-1
ScreenProtectionId=-1
NetworkSimTypeId=-1
NetworkSimQuantityId=-1
ConnectivityWifiId=-1
ConnectivityBluetoothId=-1
ConnectivityUSBId=-1
CameraRearVideoResolutionId=-1
RAM_from=0
RAM_to=512
StorageInternal_from=4
StorageInternal_to=128
StorageExternal_from=32
StorageExternal_to=256
Battery_from=2000
Battery_to=6050
Antutu_from=0
Antutu_to=29856
ScreenSize_from=3
ScreenSize_to=6
DimensionsHeight_from=13
DimensionsHeight_to=173
DimensionsWidth_from=6
DimensionsWidth_to=154
DimensionsDepth_from=0
DimensionsDepth_to=17
DimensionsWeight_from=100
DimensionsWeight_to=210
DimensionsSurface_from=67
DimensionsSurface_to=70
NetworkSarUS_from=0
NetworkSarUS_to=0
NetworkSarEU_from=0
NetworkSarEU_to=0
CameraFrontResolution_from=1
CameraFrontResolution_to=23
CameraRearResolution_from=1
CameraRearResolution_to=21
BatteryRemovable=false

HTTP requests from within Android Studio

The parsed tokens end up as arguments to the Model's respective database queries, and the values resulting of that queries' run are collected and assembled into a Perl hashref structure which is passed back to the Controller.

The Controller once more delegates the responsibility of the presentation to the Viewer which sends the new HTML page, which now contains the filtered list or subset of the initial devices' list, to the browser for rendering.



Last Updated ( Monday, 23 April 2018 )