Google har precis släppt källkoden för den officiella Google I/O 2018-appen för Android.
2018 års version utgör en fullständig omskrivning av ansökan. Under många år använde applikationen ContentProvider + SyncAdapter-arkitekturen. I år skrev Google om appen med Component Architecture och tog koden i synk med Android-teamets nuvarande rekommendationer för att bygga moderna appar.
Arkitekturbranschen
Google följde rekommendationerna i Guide to Application Architecture för att skriva modulär, testbar och underhållbar kod när de beslutade om en arkitektur för en applikation. De håller logiken från Activity och Fragment och flyttar den till ViewModels. Google observerar också data med LiveData och använder Data Binding Library för att länka UI-element i layouter till appens datakälla.
Google använde klassen Repository för att hantera dataoperationer. iOSched-data kommer från ett antal olika källor – användardata lagras i Cloud Firestore (på distans eller i lokal cache för offlineanvändning), användarinställningar och inställningar lagras i SharedPreferences, konferensdata lagras på distans och hämtas och lagras i minnet för användning av applikationen – och förvarsmodulerna ansvarar för att hantera all data och abstraktionsoperationer. Visualisera datakällor från resten av applikationen. Om Google någonsin vill byta ut Firestore-backend mot en annan datakälla i framtiden, tillåter deras arkitektur oss att göra det explicit.
Google implementerade ett lätt domänlager som sitter mellan data- och presentationslagren och hanterar diskreta delar av affärslogik bortom UI-tråden.
Google använder också Dagger2 för beroendeinjektion och vi förlitar oss främst på dagger-android för att abstrahera boilerplate-kod.
Google använde Espresso för grundläggande instrumenteringstester och JUnit och Mockito för enhetstestning.
Firebase
Användningen av Firebase-tekniker har vuxit i appen i takt med att Firebase-plattformen har mognat. Version 2018 använder följande Firebase-komponenter:
Cloud Firestore är Googles källa för all användardata (stjärnmärkta eller bokade användarhändelser). Firestore har försett Google med automatisk synkronisering och hanterar även offlinefunktioner för dem sömlöst.
Firebase molnfunktioner tillåter Google att köra backend-kod. Bokningsfunktionen är starkt beroende av användarstatuskontroll (endast deltagare får boka), kontrollera tillgänglighet och kontinuerlig bokningsstatus i Firestore.
Med Firebase Cloud Messaging kan Google meddela appar om ändringar av konferensdata på sina servrar. Konferensdata är mestadels statisk, men den förändras över tiden, särskilt efter keynoten. Appen har traditionellt använt en ping-and-fetch-modell när man arbetar med konferensdata, och Google behåller den användningen i år.
Fjärrkonfiguration har hjälpt Google att hantera konstanter i applikationen. Tidigare år har Google funnit sig oförmögen att meddela användare när data som inte är direkt relaterad till konferensschemat – WiFi-information, konferenstransferscheman etc. – ändras oväntat. Fjärrkonfiguration har hjälpt Google att uppdatera sådana värden försiktigt.
Kotlin
Google tog snart beslutet att skriva om appen från början för att passa den moderna Android-arkitekturen. Att använda Kotlin för att skriva om var ett enkelt val: Google säger att de älskar Kotlins uttrycksfulla, koncisa och kraftfulla syntax; och fann att Kotlins stöd för säkerhetsfunktioner inklusive nollbarhet och oföränderlighet gjorde deras kod mer motståndskraftig; och dra även fördel av avancerade funktioner som tillhandahålls av Ktx Android-tillägg.
Materialdesign
Vid I/O 2018 tillkännagav Material Design-teamet Material Theming, vilket ger appar mycket bättre möjlighet att anpassa Material Design för att ge sina produkter mer varumärke. När Google lanserade appen innan Material Theming kunde de inte använda alla nya komponenter men lyckades infiltrera några som den nya Bottom App Bar med en flytande Action-knapp och möjligen en kombination av element Konferensmärke.
Framtidsplaner
Omskrivning av appar ger kod i synk med Androids beprövade rekommendationer för att bygga appar, och det resulterar i en renare, mer underhållbar kodbas. Google kommer att fortsätta arbeta med appen, inkludera JetPack-komponenter när de blir tillgängliga och leta efter möjligheter att introducera plattformsfunktioner som är relevanta för appen. Utvecklare kan följa ändringar i koden på GitHub.
. .
. .
…
