Zebble
  • About Zebble
  • Compare
  • Documentation
  • Themes
  • Plug-ins
  • Contact Us

    • What is Zebble?
    • Structure of a Zebble solution
    • Zebble Designer (UWP)
    • Installing - Introduction
    • Change log
    • Introduction
    • ViewModel development
    • VM.EXE
    • View development
    • Dialogs
    • Lists and Collections
    • Tips and shortcuts
    • List views
    • ViewModel testing
    • Automatic Views
    • View development process
    • Hello World - Core Concepts
    • Layout: Sizing & Positioning
    • Event handling
    • Navigation
    • Alerts, Dialog, Prompt and toast
    • View lifecycle
    • Managing Files & Resources
    • Config & Debugging
    • Forms
    • Page templates
    • Device API
    • Animations
    • Web Api - Part 1 (reading data)
    • Web Api - Part 2 (post and delete)
    • Web Api - Part 3 (server vs client domain model)
    • Gesture events
    • View class
    • Zebble Markup (.zbl files)
    • Data Binding and MVVM
    • Stack class
    • Sizing and positioning
    • Layout examples
    • ScrollView class
    • Page class
    • Styling in Zebble
    • CSS property mapping to Zebble
    • Supported selectors
    • Zebble CSS: Under the hood
    • Inline styling
    • CSS real-time updates
    • Dynamic expressions in CSS
    • Gradient background colours
    • CSS Pseudo-classes support
    • Using Bold and Light Fonts in Zebble
    • Rotation in Zebble
    • Using custom fonts in Zebble
    • Flashing on tap using AutoFlash
    • Button
    • Carousel class
    • Checkbox class
    • DatePicker
    • Drawing class
    • FilePicker class
    • Grid class
    • IconButton class
    • ImageView
    • ItemPicker class
    • ListView & Grid classes
    • OptionsList
    • SearchInput class
    • Slider class
    • Switch class
    • Tabs Class
    • TextInput class
    • TextView
    • TimePicker
    • TreeView
    • Waiting Indicator
    • WebView class (displaying html)
    • C# Methods and Properties Of UI Components
    • Nav.Forward() vs Nav.Go()
    • Passing parameters to the destination page
    • Going Back
    • Showing Popup pages
    • Waiting class
    • Hardware Back button (e.g. Android)
    • NavigationBar class
    • Tabs class
    • Caching (pages)
    • Navigation without event handler
    • Use the Windows version
    • Logging messages for Debugging
    • Debugging Zebble/Plugin
    • Exception handling in Zebble
    • Debugging layout and styles
    • Zebble Device API
    • Device.Screen and orientation (landscape | portrait)
    • Code that should run on a specific platform
    • Using Lamp (aka Flash, LED and Torch)
    • Using Compass (Smooth compass)
    • Using Accelerometer (device angle)
    • Using Gyroscope (device motion speed)
    • How to Vibrate the device?
    • Launching the device browser
    • Finding device model and manufacturer
    • Responding to System events
    • Handling device shake event
    • Permissions
    • Permissions declaration (manifest files)
    • Sharing
    • Prompt for rating the app
    • Finding if Internet connection is available
    • Device messaging (Make a phone call, send SMS or Email)
    • Showing a local notification
    • Copying to Clipboard
    • Accessing device contacts
    • Reading and writing into Gallery (albums)
    • Playing & Recording Audio
    • Cache and temp files and folders
    • C# async / await
    • Understanding Zebble Threading
    • Debugging - the StackTrace problem
    • Not awaiting (running in parallel)
    • Timer (interval / scheduled running)
    • Post-render changes to the UI (dynamic)
    • Introduction of Geo location
    • Map & Location Services
    • Launch directions to a location (external)
    • Getting current Location
    • Tracking user location
    • Device.Media: Taking and picking photos
    • Playing an audio file
    • VideoPlayer class
    • Augmented reality
    • Recording audio
    • Virtual Reality
    • Speech Recognition
    • Recording or picking video
    • Playing remote videos in iOS
    • Text to speech
    • Introduction to the importance of Mobile Testing
    • Why and what to test
    • Testing mobile apps on different devices
    • Testing mobile apps
    • Xamarin Profiler
    • Performance optimization
    • Moving a view to another container at run-time
    • Attaching custom data (tag) to objects
    • Saving a view as image
    • Naming best practices
    • Fastest way to update your nuget package
    • Tips for Clean and Brief code
    • Splash screen and icon generation
    • Advice for passing Approval
    • Options for iOS app distribution
    • Test Release (internal and UAT)
    • Application Icons in IOS
    • Submitting to App Store
    • Releasing to App Store
    • Crash reporting
    • Optimized Release Build
    • Android - Generating an APK for manual installation
    • Payment (subscriptions & in-app purchases)
    • Introduction to push notifications
    • Registration process (App)
    • Push notification setup - iOS
    • Push notification setup - Android
    • Push notification setup - Windows
    • Sending a push message from the web app
    • Introduction
    • Connecting Zebble to Web API
    • Installation
    • Creating an API class
    • GET APIs
    • Calling a GET API (in the mobile app)
    • POST, PUT, PATCH and DELETE APIs
    • Domain Model
    • Web API and Authentication
    • Versioning
    • Uniquely identifying installations (token)
    • Settings file: config.xml
    • Standard Zebble settings
    • Login/Register with Facebook
    • Creating a composite component / plugin
    • Creating a Zebble component using Html and Javascript
    • CustomRenderedView: Third-party native components / plugins
    • Mapbox
    • Naming considerations
    • Random problems?
    • Display Keyboard for Visual Studio Android Emulator
    • iOS goes mad?
    • Configuring a Windows phone for ad-hoc testing
    • Fixing Error DEP0001 : Unexpected Error: -2147009287 while deploying Windows UWP app on device
    • Fixing Error DEP0001 : Unexpected Error: -1988945906 while deploying Windows UWP app on device
    • Unable tp Connect to the Mac agent from Visual Studio
    • Can't connect to the Mac agent from Visual Studio?
    • Choosing the CPU architecture
    • Zebble CLI
    • How to add a Device API to Zebble source?
    • About Automated UI testing
    • What should we test in mobile applications?
    • Creating an Automated UI Test in Zebble



Introduction


Developing mobile applications involves two primary concerns:

  • Logic (state, business rules, data, API integration)
  • UI

The MVVM (Model-View-ViewModel) approach is a way of separating the above concerns into distinct areas of development so that:

  • The two can be developed and tested independently
  • They can each be developed by specialised developers where
    • UI section needs Zebble UI skills
    • Logic needs C# skills only
  • Better testability of the Logic
  • Better performance, where the UI view lifecycle is managed by the framework

Development lifecycle

In the Zebble MVVM approach, the lifecycle of a typical project is the following:

Click here to see the full details.

  1. The application wireframes are designed
  2. In parallel
    • The UI graphical design will start
    • The tech lead, will design an abstract view model in plain C#, also known as ViewModel Skeleton
  3. The ViewModel Skeleton will be used as a foundation of the project by the team:
    • C# developers​ will complete the ViewModel logic implementation and integrate it with the backend APIs
    • QA engineers will design and write the test scripts
  4. Once the UI Design is ready, the Zebble UI developers should extract reusable Components from the design.
    • Each Component will represent one unique shape used once or multiple times throughout the application. It will be implemented using a C# class that inherits from a base Zebble view, or another component. dor a Zbl component (if it's a composite). Also it has its CSS definitions defined directly on the component type (rather than CssClass or ID)
  5. Once the Components and the view model skeleton are both completed, the Zebble UI developers will create ZBL markup templates to visualise the view model on the screen. 

ViewModel Skeleton

This is a vital step in the project lifecycle and provides a foundation for the whole team to collaborate effectively. The purpose of this process is to convert the structure of the UI screens and states, previously represented as visual wireframes, into their C# equivalent models.  

For each app page in the wireframes, an abstract Page class is defined.

class WelcomePage : Zebble.Mvvm.FullScreen
{
}

For every dynamic (data-based) visible element of the page, a property is defined as:public readonly Bindable<PropertyType> PropertyName = new ("Default value");

All such state objects (bindables) must have a default value (ideally not null) to provide a solid zero state. This is important to allow the UI developers to create and test the template ZBL files against those without facing null errors. 

For every interactable action on the page, a method is defined as:

public void TapLogin()
{
}
The view model classes defined at this stage are just skeleton. The methods are left empty. Also no page lifecycle methods or events are implemented. 

Defining the ViewModel skeleton in this way will provide a strongly typed object model, to orchestrate all UI development efforts. It's a technical design excercise and is normally done by the tech lead in the project, with the rest of the team participating to understand it. It should not take more than a few minutes per page to create this. So this whole excercise should not take more than a few hours for an average sized project. This should be done as the first step in the technical implementation phase, on the first day of the project.

Execution model

In a typical Zebble solution in Visual Studio, the Domain project (shared source) contains the business logic, and the App.UI project contains the UI code. There are also 3 runtime projects for each platform (UWP, Android and iOS) all under the Run folder. In MVVM model, 2 new projecs are added to the solution:

  • App.ViewModel (shared project) which contains the abstract application UI structure and logic
  • Run\VM (Console app) used for instant running and testing of the application logic and abstract UI.

All 4 runtime projects (UWP, Android, iOS and now VM) will reference the Domain and the new App.ViewModel projects.
The App.UI project will be referenced only in the platform specific ones, but not the Run\VM console app.

Run\VM (console app)

The Run\VM project plays a key role in the MVVM development model. It is a pure (c# only) runtime environment to run the application's logic.

This allows non Zebble developers, i.e. people with just C# skills, to develop the vast majority of the mobile apps' code. It also makes it much faster to run and test the app and speeds up the development iterations. In addition, it makes it easy to write end-to-end unit and integration code to test the logic and workflow of the apps based on an abstract page model, without worrying about the real UI rendering.




‹
Zebble is a product of Geeks Ltd , a software house based in London, UK. All rights are reserved.

Telephone: +44 (0)845 643 6229

Email: hello@zebble.net

Address: 66a London Road, Morden

Greater London, United Kingdom, SM4 5BE

Privacy Statement
Terms & Conditions
Contact Us