• Stars
    star
    20,285
  • Rank 1,242 (Top 0.03 %)
  • Language
  • License
    Other
  • Created over 10 years ago
  • Updated about 3 years ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Do's and Don'ts for Android development, by Futurice developers

Best practices in Android development

Avoid reinventing the wheel by following these guidelines. Lessons learned from Android developers in Futurice. If you are interested in iOS or Windows Phone development, be sure to check also our iOS Good Practices and Windows App Development Best Practices documents.

Android Arsenal Spice Program Sponsored

Summary

Use Gradle and its default project structure

Put passwords and sensitive data in gradle.properties

Use the Jackson library to parse JSON data

Don't write your own HTTP client, use OkHttp libraries

Avoid Guava and use only a few libraries due to the 65k method limit

Sail carefully when choosing between Activities and Fragments

Layout XMLs are code, organize them well

Use styles to avoid duplicate attributes in layout XMLs

Use multiple style files to avoid a single huge one

Keep your colors.xml short and DRY, just define the palette

Also keep dimens.xml DRY, define generic constants

Do not make a deep hierarchy of ViewGroups

Avoid client-side processing for WebViews, and beware of leaks

Use JUnit for unit tests, Espresso for connected (UI) tests, and AssertJ-Android for easier assertions in your Android tests

Always use ProGuard or DexGuard

Use SharedPreferences for simple persistence, otherwise ContentProviders

Use Stetho to debug your application

Use Leak Canary to find memory leaks

Use continuous integration


Android SDK

Place your Android SDK somewhere in your home directory or some other application-independent location. Some distributions of IDEs include the SDK when installed, and may place it under the same directory as the IDE. This can be bad when you need to upgrade (or reinstall) the IDE, as you may lose your SDK installation, forcing a long and tedious redownload.

Also avoid putting the SDK in a system-level directory that might need root permissions, to avoid permissions issues.

Build system

Your default option should be Gradle using the Android Gradle plugin.

It is important that your application's build process is defined by your Gradle files, rather than being reliant on IDE specific configurations. This allows for consistent builds between tools and better support for continuous integration systems.

Project structure

Although Gradle offers a large degree of flexibility in your project structure, unless you have a compelling reason to do otherwise, you should accept its default structure as this simplify your build scripts.

Gradle configuration

General structure. Follow Google's guide on Gradle for Android.

minSdkVersion: 21 We recommend to have a look at the Android version usage chart before defining the minimum API required. Remember that the statistics given are global statistics and may differ when targeting a specific regional/demographic market. It is worth mentioning that some material design features are only available on Android 5.0 (API level 21) and above. And also, from API 21, the multidex support library is not needed anymore.

Small tasks. Instead of (shell, Python, Perl, etc) scripts, you can make tasks in Gradle. Just follow Gradle's documentation for more details. Google also provides some helpful Gradle recipes, specific to Android.

Passwords. In your app's build.gradle you will need to define the signingConfigs for the release build. Here is what you should avoid:

Don't do this. This would appear in the version control system.

signingConfigs {
    release {
        // DON'T DO THIS!!
        storeFile file("myapp.keystore")
        storePassword "password123"
        keyAlias "thekey"
        keyPassword "password789"
    }
}

Instead, make a gradle.properties file which should not be added to the version control system:

KEYSTORE_PASSWORD=password123
KEY_PASSWORD=password789

That file is automatically imported by Gradle, so you can use it in build.gradle as such:

signingConfigs {
    release {
        try {
            storeFile file("myapp.keystore")
            storePassword KEYSTORE_PASSWORD
            keyAlias "thekey"
            keyPassword KEY_PASSWORD
        }
        catch (ex) {
            throw new InvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.")
        }
    }
}

Prefer Maven dependency resolution to importing jar files. If you explicitly include jar files in your project, they will be a specific frozen version, such as 2.1.1. Downloading jars and handling updates is cumbersome and is a problem that Maven already solves properly. Where possible, you should attempt to use Maven to resolve your dependencies, for example:

dependencies {
    implementation 'com.squareup.okhttp:okhttp3:3.8.0'
}

Avoid Maven dynamic dependency resolution Avoid the use of dynamic dependency versions, such as 2.1.+ as this may result in different and unstable builds or subtle, untracked differences in behavior between builds. The use of static versions such as 2.1.1 helps create a more stable, predictable and repeatable development environment.

Use different package name for non-release builds Use applicationIdSuffix for debug build type to be able to install both debug and release apk on the same device (do this also for custom build types, if you need any). This will be especially valuable after your app has been published.

android {
    buildTypes {
        debug {
            applicationIdSuffix '.debug'
            versionNameSuffix '-DEBUG'
        }

        release {
            // ...
        }
    }
}

Use different icons to distinguish the builds installed on a device—for example with different colors or an overlaid "debug" label. Gradle makes this very easy: with default project structure, simply put debug icon in app/src/debug/res and release icon in app/src/release/res. You could also change app name per build type, as well as versionName (as in the above example).

Share debug app keystore file Sharing the debug APK keystore file via the app repository saves time when testing on shared devices and avoids the uninstalling/reinstalling of the app. It also simplifies the processing of working with some Android SDKs, such as Facebook, which require the registration of a single key store hash. Unlike the release key file, the debug key file can safely be added to your repository.

Share code style formatting defintions Sharing the code style and formatting definitions via the app repository helps ensure a visually consistent code base and makes code comprehension and reviews easier.

Android Studio as your main IDE

The recommended IDE for Android development is Android Studio because it is developed and constantly updated by Google, has good support for Gradle, contains a range of useful monitoring and analysis tools and is fully tailored for Android development.

Avoid adding Android Studio's specific configuration files, such as .iml files to the version control system as these often contain configurations specific of your local machine, which won't work for your colleagues.

Libraries

Jackson is a Java library for JSON serialization and deserialization, it has a wide-scoped and versatile API, supporting various ways of processing JSON: streaming, in-memory tree model, and traditional JSON-POJO data binding.

Gson is another popular choice and being a smaller library than Jackson, you might prefer it to avoid 65k methods limitation. Also, if you are using

Moshi, another of Square's open source libraries, builds upon learnings from the development of Gson and also integrates well with Kotlin.

Networking, caching, and images. There are a couple of battle-proven solutions for performing requests to backend servers, which you should use rather than implementing your own client. We recommend basing your stack around OkHttp for efficient HTTP requests and using Retrofit to provide a typesafe layer. If you choose Retrofit, consider Picasso for loading and caching images.

Retrofit, Picasso and OkHttp are created by the same company, so they complement each other nicely and compatability issues are uncommon.

Glide is another option for loading and caching images. It has support for animated GIFs, circular images and claims of better performance than Picasso, but also a bigger method count.

RxJava is a library for Reactive Programming, in other words, handling asynchronous events. It is a powerful paradigm, but it also has a steep learning curve. We recommend taking some caution before using this library to architect the entire application. We have written some blog posts on it: [1], [2], [3], [4]. For a reference app, our open source app Freesound Android makes extensive use of RxJava 2.

If you have no previous experience with Rx, start by applying it only for responses from app's backend APIs. Alternatively, start by applying it for simple UI event handling, like click events or typing events on a search field. If you are confident in your Rx skills and want to apply it to the whole architecture, then write documentation on all the tricky parts. Keep in mind that another programmer unfamiliar to RxJava might have a very hard time maintaining the project. Do your best to help them understand your code and also Rx.

Use RxAndroid for Android threading support and RxBinding to easily create Observables from existing Android components.

Retrolambda is a Java library for using Lambda expression syntax in Android and other pre-JDK8 platforms. It helps keep your code tight and readable especially if you use a functional style, such as in RxJava.

Android Studio offers code assist support for Java 8 lambdas. If you are new to lambdas, just use the following to get started:

  • Any interface with just one method is "lambda friendly" and can be folded into the more tight syntax
  • If in doubt about parameters and such, write a normal anonymous inner class and then let Android Studio fold it into a lambda for you.

Note that from Android Studio 3.0, Retrolambda is no longer required.

Beware of the dex method limitation, and avoid using many libraries. Android apps, when packaged as a dex file, have a hard limitation of 65536 referenced methods [1] [2] [3]. You will see a fatal error on compilation if you pass the limit. For that reason, use a minimal amount of libraries, and use the dex-method-counts tool to determine which set of libraries can be used in order to stay under the limit. Especially avoid using the Guava library, since it contains over 13k methods.

Activities and Fragments

There is no consensus among the community nor Futurice developers how to best organize Android architectures with Fragments and Activities. Square even has a library for building architectures mostly with Views, bypassing the need for Fragments, but this still is not considered a widely recommendable practice in the community.

Because of Android API's history, you can loosely consider Fragments as UI pieces of a screen. In other words, Fragments are normally related to UI. Activities can be loosely considered to be controllers, they are especially important for their lifecycle and for managing state. However, you are likely to see variation in these roles: activities might take UI roles (delivering transitions between screens), and fragments might be used solely as controllers. We suggest you sail carefully, making informed decisions since there are drawbacks for choosing a fragments-only architecture, or activities-only, or views-only. Here is some advice on what to be careful with, but take them with a grain of salt:

  • Avoid using nested fragments extensively, because matryoshka bugs can occur. Use nested fragments only when it makes sense (for instance, fragments in a horizontally-sliding ViewPager inside a screen-like fragment) or if it's a well-informed decision.
  • Avoid putting too much code in Activities. Whenever possible, keep them as lightweight containers, existing in your application primarily for the lifecycle and other important Android-interfacing APIs. Prefer single-fragment activities instead of plain activities - put UI code into the activity's fragment. This makes it reusable in case you need to change it to reside in a tabbed layout, or in a multi-fragment tablet screen. Avoid having an activity without a corresponding fragment, unless you are making an informed decision.

Java packages structure

We recommend using a feature based package structure for your code. This has the following benefits:

  • Clearer feature dependency and interface boundaries.
  • Promotes encapsulation.
  • Easier to understand the components that define the feature.
  • Reduces risk of unknowingly modifying unrelated or shared code.
  • Simpler navigation: most related classes will be in the one package.
  • Easier to remove a feature.
  • Simplifies the transition to module based build structure (better build times and Instant Apps support)

The alternative approach of defining your packages by how a feature is built (by placing related Activities, Fragments, Adapters etc in separate packages) can lead to a fragmented code base with less implementation flexibility. Most importantly, it hinders your ability to comprehend your code base in terms of its primary role: to provide features for your app.

Resources

Naming. Follow the convention of prefixing the type, as in type_foo_bar.xml. Examples: fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.

Organizing layout XMLs. If you're unsure how to format a layout XML, the following convention may help.

  • One attribute per line, indented by 4 spaces
  • android:id as the first attribute always
  • android:layout_**** attributes at the top
  • style attribute at the bottom
  • Tag closer /> on its own line, to facilitate ordering and adding attributes.
  • Rather than hard coding android:text, consider using Designtime attributes available for Android Studio.
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    >

    <TextView
        android:id="@+id/name"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:text="@string/name"
        style="@style/FancyText"
        />

    <include layout="@layout/reusable_part" />

</LinearLayout>

As a rule of thumb, attributes android:layout_**** should be defined in the layout XML, while other attributes android:**** should stay in a style XML. This rule has exceptions, but in general works fine. The idea is to keep only layout (positioning, margin, sizing) and content attributes in the layout files, while keeping all appearance details (colors, padding, font) in styles files.

The exceptions are:

  • android:id should obviously be in the layout files
  • android:orientation for a LinearLayout normally makes more sense in layout files
  • android:text should be in layout files because it defines content
  • Sometimes it will make sense to make a generic style defining android:layout_width and android:layout_height but by default these should appear in the layout files

Use styles. Almost every project needs to properly use styles, because it is very common to have a repeated appearance for a view. At least you should have a common style for most text content in the application, for example:

<style name="ContentText">
    <item name="android:textSize">@dimen/font_normal</item>
    <item name="android:textColor">@color/basic_black</item>
</style>

Applied to TextViews:

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/price"
    style="@style/ContentText"
    />

You probably will need to do the same for buttons, but don't stop there yet. Go beyond and move a group of related and repeated android:**** attributes to a common style.

Split a large style file into other files. You don't need to have a single styles.xml file. Android SDK supports other files out of the box, there is nothing magical about the name styles, what matters are the XML tags <style> inside the file. Hence you can have files styles.xml, styles_home.xml, styles_item_details.xml, styles_forms.xml. Unlike resource directory names which carry some meaning for the build system, filenames in res/values can be arbitrary.

colors.xml is a color palette. There should be nothing in your colors.xml other than a mapping from a color name to an RGBA value. This helps avoid repeating RGBA values and as such will make it easy to change or refactor colors, and also will make it explicit how many different colors are being used. Normally for a aesthetic UI, it is important to reduce the variety of colors being used.

So, don't define your colors.xml like this:

<resources>
    <color name="button_foreground">#FFFFFF</color>
    <color name="button_background">#2A91BD</color>
</resources>    

Instead, do this:

<resources>
    <!-- grayscale -->
    <color name="white">#FFFFFF</color>
   
    <!-- basic colors -->
    <color name="blue">#2A91BD</color>
</resources>

Ask the designer of the application for this palette. The names do not need to be plain color names as "green", "blue", etc. Names such as "brand_primary", "brand_secondary", "brand_negative" are totally acceptable as well.

By referencing the color palette from your styles allows you to abstract the underlying colors from their usage in the app, as per:

  • colors.xml - defines only the color palette.
  • styles.xml - defines styles which reference the color palette and reflects the color usage. (e.g. the button foreground is white).
  • activity_main.xml - references the appropriate style in styles.xml to color the button.

If needed, even further separation between underlying colors and style usage can be achieved by defined an additional color resource file which references the color palette. As per:

<color name="button_foreground">@color/white</color> 
<color name="button_background">@color/blue</color> 

Then in styles.xml:

<style name="AcceptButton">
    <item name="android:foreground">@color/button_foreground</item>
    <item name="android:background">@color/button_background</item>
</style>

This approach offers improved color refactoring and more stable style definitions when multiple related styles share similar color and usage properties. However, it comes at the cost of maintaining another set of color mappings.

Treat dimens.xml like colors.xml. You should also define a "palette" of typical spacing and font sizes, for basically the same purposes as for colors. A good example of a dimens file:

<resources>

    <!-- font sizes -->
    <dimen name="font_larger">22sp</dimen>
    <dimen name="font_large">18sp</dimen>
    <dimen name="font_normal">15sp</dimen>
    <dimen name="font_small">12sp</dimen>

    <!-- typical spacing between two views -->
    <dimen name="spacing_huge">40dp</dimen>
    <dimen name="spacing_large">24dp</dimen>
    <dimen name="spacing_normal">14dp</dimen>
    <dimen name="spacing_small">10dp</dimen>
    <dimen name="spacing_tiny">4dp</dimen>

    <!-- typical sizes of views -->
    <dimen name="button_height_tall">60dp</dimen>
    <dimen name="button_height_normal">40dp</dimen>
    <dimen name="button_height_short">32dp</dimen>

</resources>

You should use the spacing_**** dimensions for layouting, in margins and paddings, instead of hard-coded values, much like strings are normally treated. This will give a consistent look-and-feel, while making it easier to organize and change styles and layouts.

strings.xml

Name your strings with keys that resemble namespaces, and don't be afraid of repeating a value for two or more keys. Languages are complex, so namespaces are necessary to bring context and break ambiguity.

Bad

<string name="network_error">Network error</string>
<string name="call_failed">Call failed</string>
<string name="map_failed">Map loading failed</string>

Good

<string name="error_message_network">Network error</string>
<string name="error_message_call">Call failed</string>
<string name="error_message_map">Map loading failed</string>

Don't write string values in all uppercase. Stick to normal text conventions (e.g., capitalize first character). If you need to display the string in all caps, then do that using for instance the attribute textAllCaps on a TextView.

Bad

<string name="error_message_call">CALL FAILED</string>

Good

<string name="error_message_call">Call failed</string>

Avoid a deep hierarchy of views. Sometimes you might be tempted to just add yet another LinearLayout, to be able to accomplish an arrangement of views. This kind of situation may occur:

<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    >

    <RelativeLayout
        ...
        >

        <LinearLayout
            ...
            >

            <LinearLayout
                ...
                >

                <LinearLayout
                    ...
                    >
                </LinearLayout>

            </LinearLayout>

        </LinearLayout>

    </RelativeLayout>

</LinearLayout>

Even if you don't witness this explicitly in a layout file, it might end up happening if you are inflating (in Java) views into other views.

A couple of problems may occur. You might experience performance problems, because there is a complex UI tree that the processor needs to handle. Another more serious issue is a possibility of StackOverflowError.

Therefore, try to keep your views hierarchy as flat as possible: learn how to use ConstraintLayout, how to optimize your layouts and to use the <merge> tag.

Beware of problems related to WebViews. When you must display a web page, for instance for a news article, avoid doing client-side processing to clean the HTML, rather ask for a "pure" HTML from the backend programmers. WebViews can also leak memory when they keep a reference to their Activity, instead of being bound to the ApplicationContext. Avoid using a WebView for simple texts or buttons, prefer the platform's widgets.

Test Frameworks

Use JUnit for unit testing Plain, Android dependency-free unit testing on the JVM is best done using Junit.

Avoid Robolectric Prior to the improved support for JUnit in the Android build system, Robolectric was promoted as a test framework seeking to provide tests "disconnected from device" for the sake of development speed. However, testing under Robolectric is inaccurate and incomplete as it works by providing mock implementations of the Android platform, which provides no guarantees of correctness. Instead, use a combination of JVM based unit tests and dedicated on-device integration tests.

Espresso makes writing UI tests easy.

AssertJ-Android an AssertJ extension library making assertions easy in Android tests Assert-J comes modules easier for you to test Android specific components, such as the Android Support, Google Play Services and Appcompat libraries.

A test assertion will look like:

// Example assertion using AssertJ-Android
assertThat(layout).isVisible()
    .isVertical()
    .hasChildCount(5);

Emulators

The performance of the Android SDK emulator, particularly the x86 variant, has improvement markedly in recent years and is now adequate for most day-to-day development scenarios. However, you should not discount the value of ensuring your application behaves correctly on real devices. Of course, testing on all possible devices is not practical, so rather focus your efforts on devices with a large market share and those most relevant to your app.

Proguard configuration

ProGuard is normally used on Android projects to shrink and obfuscate the packaged code.

Whether you are using ProGuard or not depends on your project configuration. Usually you would configure Gradle to use ProGuard when building a release APK.

buildTypes {
    debug {
        minifyEnabled false
    }
    release {
        signingConfig signingConfigs.release
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

In order to determine which code has to be preserved and which code can be discarded or obfuscated, you have to specify one or more entry points to your code. These entry points are typically classes with main methods, applets, midlets, activities, etc. Android framework uses a default configuration which can be found from SDK_HOME/tools/proguard/proguard-android.txt. Using the above configuration, custom project-specific ProGuard rules, as defined in my-project/app/proguard-rules.pro, will be appended to the default configuration.

A common problem related to ProGuard is to see the application crashing on startup with ClassNotFoundException or NoSuchFieldException or similar, even though the build command (i.e. assembleRelease) succeeded without warnings. This means one out of two things:

  1. ProGuard has removed the class, enum, method, field or annotation, considering it's not required.
  2. ProGuard has obfuscated (renamed) the class, enum or field name, but it's being used indirectly by its original name, i.e. through Java reflection.

Check app/build/outputs/proguard/release/usage.txt to see if the object in question has been removed. Check app/build/outputs/proguard/release/mapping.txt to see if the object in question has been obfuscated.

In order to prevent ProGuard from stripping away needed classes or class members, add a keep options to your ProGuard config:

-keep class com.futurice.project.MyClass { *; }

To prevent ProGuard from obfuscating classes or class members, add a keepnames:

-keepnames class com.futurice.project.MyClass { *; }

Read more at Proguard for examples.

Early in your project, make and test release build to check whether ProGuard rules are correctly retaining your dependencies. Also whenever you include new libraries or update their dependencies, make a release build and test the APK on a device. Don't wait until your app is finally version "1.0" to make a release build, you might get several unpleasant surprises and a short time to fix them.

Tip. Save the mapping.txt file for every release that you publish to your users. By retaining a copy of the mapping.txt file for each release build, you ensure that you can debug a problem if a user encounters a bug and submits an obfuscated stack trace.

DexGuard. If you need hard-core tools for optimizing, and specially obfuscating release code, consider DexGuard, a commercial software made by the same team that built ProGuard. It can also easily split Dex files to solve the 65k methods limitation.

Data storage

SharedPreferences

If you only need to persist simple values and your application runs in a single process SharedPreferences is probably enough for you. It is a good default option.

There are some situations where SharedPreferences are not suitable:

  • Performance: Your data is complex or there is a lot of it
  • Multiple processes accessing the data: You have widgets or remote services that run in their own processes and require synchronized data
  • Relational data Distinct parts of your data are relational and you want to enforce that those relationships are maintained.

You can also store more complex objects by serializing them to JSON to store them and deserializing them when retrieving. You should consider the tradeoffs when doing this as it may not be particularly performant, nor maintainable.

ContentProviders

In case SharedPreferences are not enough, you should use the platform standard ContentProviders, which are fast and process safe.

The single problem with ContentProviders is the amount of boilerplate code that is needed to set them up, as well as low quality tutorials. It is possible, however, to generate the ContentProvider by using a library such as Schematic, which significantly reduces the effort.

You still need to write some parsing code yourself to read the data objects from the Sqlite columns and vice versa. It is possible to serialize the data objects, for instance with Gson, and only persist the resulting string. In this way you lose in performance but on the other hand you do not need to declare a column for all the fields of the data class.

Using an ORM

We generally do not recommend using an Object-Relation Mapping library unless you have unusually complex data and you have a dire need. They tend to be complex and require time to learn. If you decide to go with an ORM you should pay attention to whether or not it is process safe if your application requires it, as many of the existing ORM solutions surprisingly are not.

Use Stetho

Stetho is a debug bridge for Android applications from Facebook that integrates with the Chrome desktop browser's Developer Tools. With Stetho you can easily inspect your application, most notably the network traffic. It also allows you to easily inspect and edit SQLite databases and the shared preferences in your app. You should, however, make sure that Stetho is only enabled in the debug build and not in the release build variant.

Another alternative is Chuck which, although offering slightly more simplified functionality, is still useful for testers as the logs are displayed on the device, rather than in the more complicated connected Chrome browser setup that Stetho requires.

Use LeakCanary

LeakCanary is a library that makes runtime detection and identification of memory leaks a more routine part of your application development process. See the library wiki for details on configuration and usage. Just remember to configure only the "no-op" dependency in your release build!

Use continuous integration

Continuous integration systems let you automatically build and test your project every time you push updates to version control. Continuous integration also runs static code analysis tools, generates the APK files and distributes them. Lint and Checkstyle are tools that ensure the code quality while Findbugs looks for bugs in the code.

There is a wide variety of continuous integration software which provide different features. Pricing plans might be for free if your project is open-sourced. Jenkins is a good option if you have a local server at your disposal, on the other hand Travis CI is also a recommended choice if you plan to use a cloud-based continuous integration service.

Thanks to

Antti Lammi, Joni Karppinen, Peter Tackage, Timo Tuominen, Vera Izrailit, Vihtori Mäntylä, Mark Voit, Andre Medeiros, Paul Houghton and other Futurice developers for sharing their knowledge on Android development.

Acknowledgements

 logo

This project is sponsored by Spice Program, our open source and social impact program made with love by Futurice.

License

Futurice Oy Creative Commons Attribution 4.0 International (CC BY 4.0)

More Repositories

1

ios-good-practices

Good ideas for iOS development, by Futurice developers.
10,769
star
2

pepperoni-app-kit

Pepperoni - React Native App Starter Kit for Android and iOS
JavaScript
4,643
star
3

backend-best-practices

An evolving description of general best practices for backend development.
1,942
star
4

terraform-examples

Terraform samples for all the major clouds you can copy and paste. The future, co-created.
HCL
600
star
5

windows-app-development-best-practices

A collection of best practices for Windows App and C# developers
357
star
6

meeting-room-tablet

Google Apps compatible meeting room reservator
Java
179
star
7

QA-best-practices

This is a summary of QA practices Futurice uses and recommends to be used.
126
star
8

futurice-ldap-user-manager

FUM is a user management system for LDAP (Lightweight Directory Access Protocol).
JavaScript
112
star
9

metalsmith-prismic-template

Template for static site generation with prismic.io and metalsmith
JavaScript
98
star
10

iot-service-kit

Internet of Things (IoT) Design Kit (cards, maps, 3D printable pieces) for rapid service concept iteration
93
star
11

field-ops-guide

A booklet to help you survive a software project
89
star
12

freesound-android

Unofficial Android client for the Freesound Project
Java
84
star
13

whereareyou

Passive indoor localization using WiFi signal strength
Python
80
star
14

power-ui

power.futurice.com new UI
JavaScript
57
star
15

project-handover-checklist

List of checkboxes for IT project handover
52
star
16

unity-good-practices

Good ideas for Unity3D development, by Futurice developers. http://www.futurice.com
49
star
17

vor

The new IoT Office Experience.
Java
46
star
18

android-jenkins-docker

Docker image with Jenkins that can build Android apps.
39
star
19

HoloLens-and-Leap-Motion

C#
37
star
20

alley-oop

Dynamic DNS server with an integrated Let's Encrypt proxy, enabling easy HTTPS and WSS for web servers on a local network (LAN)
Go
37
star
21

wappuapp-client

Android and iOS clients for the Futurice Whappu app!
JavaScript
33
star
22

projectnavigationgame

A quest for unknown unknowns, a board game to check the project readiness.
32
star
23

spice-hate_speech_detection

A SPICE-program funded project where the goal is to detect hate speech in social media.
Python
31
star
24

space-tyckiting

Futurice Space Tyckiting: Earth Domination Tour
JavaScript
30
star
25

clojure-workshop

Basic Clojure training material for a one day workshop
Clojure
27
star
26

symptomradar

Symptomradar (Oiretutka) crowdsources coronavirus symptoms from news media audience
TypeScript
25
star
27

spicehours

JavaScript
23
star
28

futurice-super

The purpose of this project is to promote transparency of the sales pipeline and help sales decide what cases to prioritize. This would be done by providing an interface for tribe-members to see upcoming cases and allow them to vote for the cases they find interesting.
JavaScript
23
star
29

file-sharing

Simple anonymous encrypting file service
JavaScript
22
star
30

spiceprogram

Spice Program website and source files for OSS docs
HTML
22
star
31

futuhours-next

A simple frontend for logging work hours
Elm
19
star
32

hannotaatio

Hannotaatio - A visual website feedback tool
JavaScript
19
star
33

festapp-server

JavaScript
18
star
34

minimal-play2

Play framework example application
Scala
18
star
35

rx-android-chat-exercise

Android client for a chat application RxJava exercise
Java
17
star
36

sns-push-notification-service

Simple proxy server for abstracting and simplifying SNS API
Python
17
star
37

futuswarm

Docker Swarm PaaS on AWS
Shell
17
star
38

reactivex-training

Some training material for a full-day ReactiveX training
JavaScript
16
star
39

cv-generator

Tool to generate single slide CVs
Python
16
star
40

vpn-management-server

Server for managing OpenVPN certificates
Python
15
star
41

wappuapp-backend

API for Wappu app client
JavaScript
14
star
42

gif-disco

GIF Disco is a virtual night club - a brilliant addition to any party. Take over the dance floor by recording your moves into an infinitely looping GIF animation.
Python
14
star
43

corona-simulations

Historical Estimates & Model Predictions for COVID-19 in Finland
Svelte
13
star
44

android-meetup-ui-challenge

Material Design UI challenge for the hackathon at Android Meet-up March 2015
Java
13
star
45

festapp-android

festapp Android client
Java
12
star
46

terraform-monitor-lambda

Monitors a Terraform repository and reports on configuration drift: changes that are in the repo, but not in the deployed infra, or vice versa. Hooks up to dashboards and alerts via CloudWatch or InfluxDB.
TypeScript
12
star
47

op-hackathon-templates

App templates demonstrating OP's API usage with Cycle.js
JavaScript
12
star
48

lean-service-creation-kit

Lean Service Creation (LSC) Kit
12
star
49

taxibutton

Futurice Taxi Button
JavaScript
11
star
50

spotify-hubot

Flowdock bot which adds linked Spotify tracks to a playlist
JavaScript
11
star
51

ansible-sentry

Ansible role for Sentry
Python
10
star
52

secret

For managing secrets.
Python
10
star
53

facegame

Facegame
JavaScript
10
star
54

haskell-aws-lambda-kleisli

Run Haskell on AWS Lambda. Deprecated: consider using https://github.com/phadej/aws-lambda-haskell-runtime
Haskell
10
star
55

intro-to-object-detection

instruction and sample codes to get started with object detection in dlib-python
Python
9
star
56

vpn-management-client

Java
9
star
57

festapp-ios

festapp iOS client
Objective-C
9
star
58

futulokki

Website and camera stream for Tampere office's neighbor - seagull named Steven
JavaScript
9
star
59

futuLog

A service to trace contacts in an office environment
TypeScript
9
star
60

Futility

Reusable code for iOS projects
Objective-C
9
star
61

process-arrow

Polymer element for showing a process arrow (progress diagram)
HTML
8
star
62

futurice-academy-homework-assignment

8
star
63

sentry

Dockerized Sentry installation
Python
7
star
64

myRetroGenerator

A static site generator that converts a markdown version of myRetro to an HTML page with the canvas
Haskell
7
star
65

event-app-client

Futurice internal event app
JavaScript
7
star
66

grunt-transifex-resjson

Grunt tasks for managing RESJSON resource files in Transifex translation service
JavaScript
7
star
67

android-rxmvvmdi

Project for introducing Android developers to how one can combine Rx, MVVM, DI, data-binding, and unit testing concepts
Java
7
star
68

jalapeno

CLI for creating, managing and sharing spiced up templates
Go
7
star
69

haskell-futurice-prelude

Futurice Haskell Prelude
Haskell
6
star
70

pepperoni-sample-app

Sample app to demonstrate how to create a React Native app with Pepperoni starter kit (http://getpepperoni.com)
JavaScript
6
star
71

react-native-best-practices

A slightly polemic repository with shared knowledge and best practices from React Native projects at Futurice.
6
star
72

prahapp-client

React Native application for Futuparty
Objective-C
6
star
73

haskell-futurice-site

Python
6
star
74

redux-training

JavaScript
6
star
75

futurice-principles-ethical-ai

Futurice Principles for Ethical AI
6
star
76

hackjunction-multitaction-demo

A demo project for HackJunction to demonstrate the Multitaction multitouch displays.
C#
6
star
77

haskell-flowdock-grep

Grep Flowdock logs
Haskell
6
star
78

heroku-cron

A simple cron-like process to run in worker dyno.
Haskell
5
star
79

fum2github

Compare Futurice FUM and GitHub users
Haskell
5
star
80

android-meetup-rxjava-challenge

RxJava challenge for the hackathon at Android Meet-up March 2015
Java
5
star
81

rxjava-android-exercise

Java
5
star
82

django-saber

Python
5
star
83

macsis

Access control based on Google account domain
JavaScript
5
star
84

rx-android-exercise

Java
5
star
85

futuit-hacks

Futurice IT miscellaneous scripts and tooling
Python
5
star
86

vaskapp

Vask App Client
Objective-C
5
star
87

haskell-flowdock-rest

Haskell bindings to Flowdock REST API
Haskell
5
star
88

sanko-game

Java
4
star
89

metalsmith-prismic-server

npm app package for running on Heroku or similar to compile and deploy content for sites built with metalsmith-prismic-template
JavaScript
4
star
90

ansible-cassandra

4
star
91

google-apps-contacts-copier

Python
4
star
92

docker-base-images

Base docker images for internal service
Dockerfile
4
star
93

machine-learning-best-practices

A collection of materials, pointers, and practices in approaching machine learning projects
4
star
94

jolt-wall

A small elm project to display jolts from Flowdock
Elm
4
star
95

hemmo-app

Mobiili applikaatio Pelastakaa Lapset ry:lle tukiperhevierailujen palautekyselyjä varten
JavaScript
4
star
96

django-history

Django History -- track changes over time for all changes
Python
4
star
97

wwweeklies.com

Repository for wwweeklies.com
HTML
4
star
98

PythonInBrowser

Chilicorn code club site
Python
4
star
99

uwp-reusables

A library of controls and logic that get reused frequently.
C#
4
star
100

djangomi

Python
4
star