Links

Monday, December 28, 2015

1. Specify onClick and onLongClick at once

Normally, most of the buttons does nothing on long click, because programmers doesn't specifically allocate any behavior on it. In the current touch-input UIs, there are no common visual guide for user to determine something is able to being long touched or not; So I believe that it is better for user that buttons are assigned a default behavior for long touch. However, this was generally not so fun to write:

Friday, August 14, 2015

Incompatible changes

Scaloid 4.0 is best with Android API Level 16, while still supports Level 10

Scaloid 4.0 distribution is compiled with Android API Level 16, still retaining compatibility with Level 10. Accessor methods and deprecation warning is based on API Level 16, so you have to carefully check the availability of API if you target lower version of Android. In our experience on building an App for Gingerbread, currently we found no obstruction that prevents building a Scaloid app for older devices.

To compile with Scaloid 4.0, you have to specify build time Android API in project.properties file as android-16 or higher.

LocalServiceConnection

Usual use case of LocalServiceConnection is:

val service = new LocalServiceConnection[MyService]
//...
service {
myService => // do something with myService
}

The implementation of apply() is changed to:

def apply[T](f: S => Unit): Unit = service.fold(onConnected(f))(f)

The block will be executed later if the service is not connected yet. Formally it was just did nothing when the service is not connected yet. This behavior now becomes ifAvailable. Then all the code using apply(...) should be changed to ifAvailable(...).

SArrayAdapter

Constructor parameter of SArrayAdapter is now java.util.List.

spinnerDialog

spinnerDialog returns Future[ProgressDialog].

End of incompatible changes

More convenient press-and-hold action

We provided the press-and-hold action callback from the last release. The sample code below increases the number on the TextView in every 100 milliseconds:

Thursday, August 6, 2015

XML is wordy and not programmable. One of the major goal of Scaloid is to replace XMLs with Scala code, to be more concise, type-safe and programmable. Scaloid 4.0-RC2 provides a new way to build StateListDrawable without XML. For example, given the XML drawable selector:

It is clearly better than old-Android-API, but it still has some limitations:

No compile-time name checks
If there are a typo on the key name of the preferences, compiler does not warn you. It will be a nightmare if some preference name is used in multiple places and only one has a typo.

Key names should be a Scala symbol name
For example, a key.name@with:special#chars cannot be accessed with Scala type dynamic

Inconsistencies with method and preference access
In the above example, pref.remove(...) is a pre-defined method call, while pref.executionCount(...) is a preference access.

Scaloid 4.0-RC2 contains a new way to access Preferences. Let's look into it:

It is cleaner, performs compile-time validation, and better semantics. Scala macro accesses the value name to be assigned, executionCount in this example. If you want a keyname has special characters, we provide an alternative:

val executionCount = preferenceVar("execution.count", 0)

Preference values does not have a dependency on android.context.Context when it is created. A Context is only needed when it is actually being accessed (e.g. reading, writing, removing). So, it can be a property of plain object (static method in Java terms), and can be defined only once:

Friday, April 17, 2015

Today, I released a release candidate of Scaloid 4.0. This version has several feature additions and a notable change about versioning:

Scaloid 4.0 is best with Android API Level 16, while still supports Level 10

Scaloid 4.0 distribution is compiled with Android API Level 16, still retaining compatibility with Level 10. Accessor methods and deprecation warning is based on API Level 16, so you have to carefully check the availability of API if you target lower version of Android. In our experience on building an App for Gingerbread, currently we found no obstruction that prevents building a Scaloid app for older devices.

Notes for incompatible changes

To compile with Scaloid 4.0, you have to specify build time Android API in project.properties file as android-16 or higher.

This is a shame. Using Scala macros, I made a new function put(Any*) on Intent, that can be used like this:

new Intent().put(valueA, valueB, valueC)

Intents can be started

To start an activity from the intent above, we are writing like this:

startActivity(SIntent[MyActivity].put(valueA, valueB, valueC))

This is concise, but not really readable. From this version, we can rewrite it:

new Intent().put(valueA, valueB, valueC).start[MyActivity]

This looks more natural because it can be translated one-to-one in plain English:

Create a new Intent, and put values A, B, and C. Then, start the MyActivity.

Wrap or fill

I found that I am using layout properties wrap and fill very frequently. Because layout properties should written in <> blocks, we have a lot of <> and <> in our code. These idioms makes sense in terms of consistency, but not very pleasing. Because Scaloid is not stingy with providing shorthands, I dropped out <> from it.

Now we can specify 'wrap-ness' of a TextView like this:

textView.wrap

This looks trivial at first. However, think about how many times you are using it.

Additionally, we provide functions fw and wf, that is equivalent to <> and <> respectively.

Drops support Scala 2.10

Scaloid 3.6 is built on Scala 2.11.3, so you can use it with other Scala 2.11.x versions. From this version, I drops Scala 2.10 support to use full potential of recent improvements on macros.

Building Scala 2.11.3 on Android

I've found that building Android apps with Scala 2.11.3 (and 2.11.4) results more proguard warning, that prevents Android projects from being built. The error messages are: