GTranslate

 

SQLite, Spinners and Dates: C# and Monodroid

 

 Programming language & Environment

Why C#?

C# is simply the best general purpose language on the scene today. As a descendant of C (and still able to compile and run C code), and highly influenced by the best of C++, C# is the heir of the programming tradition that has produced the largest amount of operating system, device driver and application software in all of computer science. (Second place is held by COBOL; Java is in a distant third place, and fading as its inherent design-related shortcomings become ever more evident. [Java was designed, like Pascal, to keep programmers from doing things, not to support or simplify their efforts; and it is unable to escape that legacy.])

With .NET on Windows devices and the Mono libraries elsewhere, there isn't a compelling reason now not to use C# to the exclusion of all other would-be portable—and/or native—programming environments. Unlike Java, et al., C# can be used across the whole gamut of development: for writing portable apps for smart devices, for full applications, all the way down to the hardware, for writing device drivers. With Java and Objective-C you get a flat-head and a philips-head screwdriver, respectively—workable, but because of definition and support limits, and resulting implementation problems, still single-purpose tools. With C# you get the entire toolbox—and your choice of pickups to haul it around in.

 

Why Xamarin’s Monodroid/Monotouch?

C# combined with Xamarin's products have been the best I’ve found so far for cross-platform dev on hand-held devices, and the support I’ve gotten from Xamarin (bug reports, updates, upgrades, etc.) has been extremely good, and personal, even personable.

Although his blog itself is from within Xamarin, Nat Friedman states it well in his list: Eight Reasons C-Sharp Is The Best Language For Mobile Development.

 

♦ Why start with Android examples?

The reason is quite iSimple. Apple has put so many costly hardware and software requirements in the way of iDevice development that almost everyone starting out will be drawn toward the Android platform both for lower cost, and for ease and speed of installation and set up. This will mean, in practice that the newest and most innovative apps [which always come from outside of the well-funded, profit-before-innovation organizations] will almost always appear first on Android, and that i* owners will be forced to wait.

 

Is this all you're going to have?

I have plans to add more examples as I identify areas that are currently under-exampled or poorly explained, or that could benefit from alternative approaches. So check back.

 

You write in a rather formal style.

Sorry, but that may be how it comes across. I speak General American Dialect, and pay particular importance to logical correctness and stylistic suitability. (That is, unless I'm hit by too close a deadline [or I get bit-in-the-ass by cut-and-paste] …) [For more info, see How To Not Like Talk Or Like Write, Dude, particularly item 1 linked from that page.]

 

The Database System

SQLite is the built-in database system both on Android objects and on Apple’s devices. Although Microsoft installs a version of its own DBMS on hand-helds running Windows, there are programming interfaces available that will let you write to that DBMS still using cross-platform, SQLite-based syntax.

These examples address the DBMS with code that is as platform-independent a way as can be determined at this time. Because using the DBMS makes no sense without a displaying platform, apps accessing the DBMS will require front-end tweaking to move them between specific platforms, away from these Android 2.3.2-minimal examples.

 

The Purpose of these Examples

There is a multitude of examples of using SQLite out on the Internet. However, in reviewing them, I found none of them actually do things with a database that apply to more advanced, real-life problems. For example, none of them use foreign keys within their example schemata.

So, I offer here a series of simple excursions into developing database-based “smart” device applications handling or displaying data. We’ll start simple and then add complexity: additional tables and relationships, and connections to more interface capabilities, like spinners and date-time controls.

There is some "over coding" within the examples simply to demonstrate varieties in which things can be accomplished. Extra credit if you can find 'em!

 

General notes:

♦ These examples have a start-up class derived from Application, one that functions more-or-less like a ‘main’ block: MainApp, but one that is itself not an activity. This arrangement is particularly useful for allowing application start-up, run-once code to be invoked from within the MainApp.OnCreate() method. It is from this module that the database is initialized within these examples.

♦ The examples also contain a MainActivity class that extends the built-in Activity class. This is the first activity launched by the loader after the MainApp.OnCreate() listener has completed its tasks.

MainActivity loads the ‘home’ screen activity of the app, implemented in the ViewDogActivity class.

♦ These examples use an Interface into a ‘repository’ that holds the actual code accessing the database. There is only a single implementation of the database interface in each of these examples. However, other implementations of that interface could be added, such as one using the Android-specific SQLite helper routines, or to utilize the Microsoft DBMS directly on Windows devices. But this is left to the reader as further exercise, if desired.


DBExample0 The Initial, Baseline App
With a single-table database whose rows are used in CRUD (create, retrieve, update & delete) activity-screens.
♦ Source files: DBExample0.zip

DBExample1 The Baseline App Plus Table With Foreign Key & Spinner
Data flow is separated between classes, one echoing the DBMS tables and another that holds the fields used in display-forms.
The ‘Source’ text column in the original table is converted to an indexed key into the added `Sources` table.
A
SourceSpinner class is added to handle spinner operations while choosing a source on either adding or editing a Dog record.
♦ Source files: DBExample1.zip

DBExample2 Example1 Plus DateTime Handling & Ability To Add Rows To The Foreign-Key Table 
A DateTime field is added to the main C# data-class, with code added to manipulate the field's ‘tick’ value as an integer within the DBMS table. This example also adds the ability to insert a new `Source` record when adding or editing a dog's record.
♦ Source files: DBExample2.zip

  


Note
: All article text and software recipes herein presented or offered in source-code format are
solely for educational purposes,
as expositions of concept or usage having no otherwise specified or recommended utility.

All code is provided strictly “as is”, with no warranty granted or implied as to its correctness,
error-content, or its ability to run on any particular hardware, whatsoever.
Any use other than for education or research is wholly at the user’s sole risk and responsibility.

This code is placed into the public domain.

You are free to use it in any way. However, if you do find it useful,
a link to this site, or a favorable mention, would be greatly appreciated.

Other than as a customer, the author has no connection in any way to Xamarin or any other company or product listed;
and no association, recommendation, or advice, in any degree or condition,
should be assumed by any person to exist with any company listed, cited or referred to.

 

 

Site design and contents (other than where otherwise noted)
Copyright © Eduard Qualls, 2013 - 2016.