Almost all Kevins: #Android development ideas for #ContentProviders, #ColorAdjustment, #transitions, #CodeTesting
Posted on February 27th, 2015
02/25/2015 @Tumblr 35 E 21st St., NY
Five speakers gave lightning talks about a diverse set of topics.
Kevin Grant – Developing with Motion in Mind: Strategies for Motion-First development in your Android applications.
Kevin Coughlin – Working with ORMs: Differences between Realm and Cupboard, and discusses his experience with both.
Kevin Schultz – Building Maintainable Android Applications (and maybe a quick talk on the new Android testing tools that were just released!)
Eric Leong – OpenGL Basic on Android: How to use OpenGL in your apps when working with images and videos.
Zack Parness – Hiccup: an open source library that tries to simplify the way ContentProviders are used for data access.
In the first talk, Zak Parness talked about the advantages of using #Hiccup as a #ContentProvider on the server side. Hiccup provides a #RESTful backend which separates the UI from the server content. This structure simplifies the program logic, making it easier to maintain and upgrade each side without changing the other.
Next, Kevin Coughlin introduced two ORMs (Object-relational mapping – converting data between incompatible type systems).
#Cupboard is a SQLite wrapper that uses POJOs (plain old Java object) which performs the SQL function PUT, GET, UPDATE, DELETE, QUERY.
#Realm – database approach. Clean builder-type API, cross-platform
But – in beta, need getters/setters, performance? No content provider support, no migration support, crashes.
The third speaker, Eric Leong talked about performing color correction using #OpenGL on Android. Color correction processes each pixel independently of other pixels thereby allowing for parallel processing of the image using the GPU. Eric talked about the importance of minimizing movement of data between the CPU and the GPU and how openGL converts polygons in the image to fragments and then puts a texture on the fragment. The color correction is then done on the texture.
Kevin Grant next talked about how screen transitions improve the user experience and how to implement them in the lollipop version of the operating system.
He first showed how an interface without transitions can be hard to navigate. In such an interface, the user presses a button and the screen immediately changes. This provides no visual hints on which button was pressed and how the button-press relates to the new screen. This increases the memory load on the user and can make it hard for the user to remember where they are when they click through multiple screens. He used Instagram and Twitch as examples of mobile interfaces which have this problem.
Kevin next walked the audience through an interaction on Google Play Games. It using fades and gradual scaling to make it much easier to navigate the site.
Kevin next talked about how to implement transitions. SDK 21 / Lollipop is the first Android OS that provides the tools to easily implement transitions. Lollipop has the ability to render two images parts of which are both displayed during the transition and SKD 21 has the functions in the toolkit to take advantage of this.
In SDK 21 there are two types of transitions:
- Hero transitions – one screen to the next – default to move
- Content transitions – can enter or leave: fade, explode, slide – default to fade
The toolkit includes routines to enter and exit the transitions, callbacks to create complex transitions and listeners executed once the transition is completed. Further information is available from Alex Lockwood.
Aliya Merali from Coalition for Queens is looking for volunteers to each coding to 30 students enrolled in a 20 hours/week course. The program seeks to give a diverse set of students the tools to become professional programmers.
In the final presentation, Kevin Schultz @Gilt spoke about the importance of testing strategies during code development. He emphasized that every developer has a testing strategy with the highest cost strategy being no formalized testing strategy which means that the customer does the testing. Besides being customer unfriendly, this strategy is also slows the development process.
- He likes unit tests as the backbone of your test suite. It is narrow in scope and quick to test. His main recommendation was to property structure the code. One standard recommendation is separating the computation and the user interface. In terms of typical Java code for Android apps, this means separating the Fragment (or Activity) from the viewModel. Some ways to do this include:
- The fragment is responsible for loading models, networking, finding views, treading
- The viewModel is responsible for business logic
- Keep references to views entirely in the ViewModel
- Do not pass the context to the viewModel, pass in resources
- Don’t have methods for each view.