FIT2081 Lecture Notes - Lecture 1: Web Application, Mobile Browser, Web Developer
12 Jun 2018
School
Department
Course
Professor
SDK$(Software$Development$Kit)
•
API$(Application$Programming$
Interface)
•
IDE$(Integrated$Development$
Environment)
•
3$types$of$mobile$apps$in$an$Android:
Mobile$web apps
1.
Native apps
2.
Hybrid apps
Thin$native$app$shell$containing$a$web$app
a.
Cross-compiler$used$to$convert$code$into$native$apps$executable$ by$
each$required$platform$(eg.Xamarin)
b.
3.
Comparison$factors:
Cost%for%developer
Native$need$to$write$code$specific$to$OSs$-more$expensive
Need$more$technically$sophisticated,$costly$developers
§
○
Hybrid$and$web$-web$developer$skills$cheaper
○
•
Development
Native$and$hybrid$use$languages$eg.$Java$and$APIs
○
Web$uses$HTML/CSS/JS
○
•
UI%look%and%feel%(L&F)
Native$and$hybrid$better$quality$than$web
Web$uses$HTML5$which$allows$development$of$sophisticated$UI,$
but$often$still$a$different$user$experience
§
○
•
Availability
Native$and$hybrid$on$stores$and$req$purchase$and$download
○
Web$available$as$long$as$there$is$a$network
○
•
Offline
Native$and$hybrid$local$file$storage
○
Web$-data$storage$limited$since$in-browser
○
•
Discoverability
Native$and$hybrid$on$app$stores
○
Web$using$URL$and$bookmarking
○
•
Installation
Native$and$hybrid$need$to$install
○
Web$no$need$(mobile$browser)
○
•
Speed
Native$and$hybrid$always$better,$esp$for$fluid,$complex$graphics
○
Web$slower,$but$high$speeds$less$necessary$anyway
○
•
Security
Native$no$risks
○
Web$and$hybrid$subject$to$security$risks
○
•
Content%restrictions,%approval%process,%fees
Web$practically$ free$of$encumbrances
○
Native$and$hybrid$share$purchase$price$with$app$store
For$Apple,$lengthy$approval$process
§
○
•
Maintenance%(updates)
Web$instantaneous$to$all$platforms/centralised
○
Native$and$hybrid$have$consistent$platform$updates$but$could$still$
have$delays
○
•
*capability%against%platforms•
Access%to%resources/features•
Cross-platform•
Upgradability•
Java$things:
Super$and$sub$classes•
Abstract$classes$and$methods•
@Override•
Instance$vars should$be$private$(directly$accessible$in$subclasses)•
Class$inherits from$all$ancestors,$not$just$its$parent•
toString()•
Upcasting=$polymorphism using$inheritance (and$vice$versa)•
Downcasting?•
Interface =$contract/promise$("implements")
Only$1$super$class but$can$implement$multiple$interfaces
○
Is$a$type
○
•
How%emulator%and%Android%Studio%work%(using%IDE,%APK)
Computer:
Runs$IDE•
Creates$APK$and$pushes$to$virtual/real$device•
Virtual/real$device:
Runs$an$instance$of$the$Android$OS$that$unpacks$the$pushed$APK•
Installs$the$app$and$runs$it•
AppCompatActivity =$$a$backwardly$compatible$Activity$class
Base$class$for$activities$that$use$the$support$library$action$bar$features•
Has$methods$like:
Public
setContentView(View view)
Sets$the$Activity$content$to$an$explicit$view□
§
findViewById(int id)
Find$a$view$identified$by$the$android:id XML$
attribute$processed$in$onCreate(Bundle)
□
§
getMenuInflater()
§
getResources
§
getSupportActionBar()
§
○
Protected
onCreate(Bundle savedInstanceState),
onDestroy()
§
onStart(), onStop()
§
onSaveInstanceState(Bundle outState)
§
○
Inherited
getSupportFragmentManager()
§
onBackPressed()
§
○
•
There%is%a%mobile%web%app%that%is%a%website.%What%does%this%mean?
This$app$is$built$using$any$website$development$technology$designed$for$smart$
device$displays$and$accessed$by$a$device’s$browser$like$any$other$website.
For$example,$a$mobile$web$game$like$ a$Facebook$game,$which$you$only$need$a$
browser$to$open,$instead$of$having$to$download$it$from$an$app$store.
A%thin%native%client%is%to%a%hybrid%app%as%a%mobile$browser$is%to%a%mobile%web%
app.%
(what$hosts$it)
→
Java%code%that%counts%negative%numbers%in%an%array%of%size%N.
int count = 0;
for (int element : array) {
if(element < 0){
count++;
}
}
System.out.println(count);
Week$1
Tuesday,$ 29$May$2018
10:26
Document Summary
3 types of mobile apps in an android: Thin native app shell containing a web app. Cross-compiler used to convert code into native apps executable by each required platform (eg. xamarin) Native need to write code specific to oss - more expensive. Hybrid and web - web developer skills cheaper. Native and hybrid use languages eg. java and apis. Web uses html5 which allows development of sophisticated ui, but often still a different user experience. Native and hybrid on stores and req purchase and download. Web available as long as there is a network. Native and hybrid always better, esp for fluid, complex graphics. Web slower, but high speeds less necessary anyway. Native and hybrid share purchase price with app store. Native and hybrid have consistent platform updates but could still have delays. How emulator and android studio work (using ide, apk) Runs an instance of the android os that unpacks the pushed apk.
