Having said that, when it comes down to exploring new opportunities that could lead us to innovation, the way we build and tell these stories can lead us to success (or not). But why isn’t that so easy? Because we are programmed with many behavioral mechanisms that prevent us from acting. To briefly illustrate, one of these behavioral mechanisms is the so-called “negativity bias.”

Understanding our bias

Essentially, this means that we are much more likely to focus on the dwell of something that’s gone wrong than on things that have gone well. This scenario has been built by our society and it is intrinsic to our collective unconscious. This is what kept us safe in prehistoric times when faced with situations of danger, but it is not what is going to make us succeed in welcoming new ideas, for example, innovation.

This also has a direct impact on our power to continue improving and bringing transformation to the organizations we’re a part of.

Transformation is one of the most challenging things leaders face. What I mean when I say transformation is mapping possibilities, possible futures that we can materialize, and then successfully overcoming any obstacles preventing us to achieve the desired goal. At Cheesecake Labs, transformation is undergoing, leading us to realign and improve everything constantly.

With that in mind, can we transform organizations and products without transforming people and the way they connect in order to build the future? That’s when storytelling comes to play.

Where to start

I always say that if you don’t know where to start, you should start with the stories. The stories you tell your colleagues, your leaders, yourself. A single-story carries one of the most amazing powers it can have: the power to transform.

These stories may answer meaningful (and strategic) questions: what are the other possibilities? What does the future look like? What problems are you trying to solve? What path makes more sense to pursue in order to reach the desired goal? I’m always asking myself: how can we write better stories together?

A single-story has the potential to explore new possible futures, explain the strategy required to get there, and attract other people to make it happen. Stories have the potential to motivate an organizational transformation, and that means innovation!

Effective storytellers can reach the golden spot to innovation: engage people to embark on this new idea/product/future, and all of this is done in a structured way.

Essential elements of a strategic narrative

I believe that a great story includes the human context (what will be done and by whom), the shared purpose (why do you want others to embrace this story with you?) and what makes the story unique (the desired outcome or the possible future that you envision). It is not only the outcome that makes a story unique but also the journey itself.

To illustrate how you can act hands-on, I’ve used Friends TV series episodes as an example because it is the greatest tv series in the whole world! You can also check this great book as a reference as well as other frameworks.

The Arc

The narrative arc is a term that describes a story’s full progression. It visually evokes the idea that every story has a relatively calm beginning, a middle where tension, character conflict, and narrative momentum builds to a peak, and an end where the conflict is resolved.

You may already be familiar with one classic example of the story arc: a startup idea, a challenging beginning, reaching success. This may sound oversimplified, and it is. Adding complexity to a basic story arc is part of what differs one story from another, even when they’re ostensibly dealing with the same ideas.

On a daily basis routine, this means I may engage my team in new projects using the arc narrative. First I give them specific information about our new partners, their interests and settings like: who and where are them? What do they feel about this product? How did they get to us? Having said that, I climb up the story with the wrinkles: what problem do they want to solve with this product? Which pains and frustrations do they have? With that in mind we can reach the climax with the team’s purpose on how they can help it and all the skills needed to deliver an excellent product. The falling action (resolution) is the part of the story we’ll write together.

The Hero’s Journey

Monomyth (also called the hero’s journey) first described by Joseph Campbell is a story structure found in many movies and tales across the world.

It’s an adventurous and challenging journey of a Hero, who moves from certainty to uncertainty and returns safely with reward. For this article’s point of interest, “hero” can be a disruptive idea that is born through uncertain conditions as we know it (this point in human history is a great example) but has the power to bring extraordinary and reliable results (reward).

As an example, I’m using one of Friends episode to illustrate the Hero’s Journey structure as follows:

Science Fiction

Science fiction is a great tool to inspire thinking about new and possible futures in addition to the impact of technology on human lives. Silicon Valley has a deep connection with Science Fiction (as an example, the book Fahrenheit 451 written in 1953 inspired earbuds creation).

Imagine the future 5 to 10 years from now. Consider real-life problems using technology. Think about the stories behind it. Write about it. At this point, do not worry too much about how it’s all going to happen. Just take the time to think about the future. As described in “Leading Transformation“, from this point forward, a multitude of options will present itself. Once that is achieved you will be able to write a strategic narrative about how the future could be. Use the arc or the hero journey (the user) with a dilemma (a real-life problem) and a resolution.

We may explore possible futures using the power of science fiction. Science fiction can be used as part of a product creation process. With Sci-fi, there are no boundaries. Out of the box thinking is not only allowed, but encouraged. We can create little scenarios or even larger dramas to integrate the product we’re building into a narrative that is engaging and aligned with the product’s purpose.

What is your setting (time)? The future, an alternative timeline or historical past that conflicts with historical background? Where does the story take place? Outer space, other worlds, or alternative versions of the earth? What are the narrative elements? A new technology, a new product, a new scientific principle or a new political system? These are some of the questions to start creating a Sci-fi narrative. Explore. Dream. Discover.

Storytelling as a Project Manager

I consider it crucial to question ourselves how we are telling the stories about our efforts towards innovation. We need to realize the power of stories and embrace the fact that it is determinant to our efforts to succeed.

Conversely, as a Project Manager at Cheesecake Labs, I’m constantly challenging myself considering the team’s unique perspectives in a positive manner, using these tools (science fiction, the hero’s journey, the arc) as I see fit. It is important to maintain a continuous conversation about the products that we are building – we are always trying to ask as well as answering the right questions together in order to build it meaningfully – truly adding value to our partner’s businesses and Cakers. We believe in the stories we’re writing while developing products, always keeping the drive to help build successful tech products that solve real-world problems.

Working together through the stories, the best way possible – this is how we bring innovation to the table.

References

Fahrenheit 451
Leading Transformation
The hero’s journey

The post Storytelling your way to innovation appeared first on Cheesecake Labs.

For the purpose of this post, I will use the following patterns and packages:

– React Navigation: Routing and navigation for your React Native apps;

– Axios: Promise-based HTTP client for the browser and node.js.

Follow the required installation steps on Getting Started · React Native. After configuring the React Native CLI on your machine, verify if  `react-native -v` is available on your terminal.

You should get a return similar to this:

$ react-native-cli: 2.0.1
$ react-native: n/a - not inside a React Native project directory

So we can proceed to create our project.

Cheesecake Labs is the top #5 React Native Development Company and has delivered quality cross-platform applications to a number of clients.

Creating a project from Scratch

Choose a directory of your choice to create our base project using the following command:

$ react-native init ReactNativeCklExample

After the execution, you can access the directory using the cd ReactNativeCklExample. You will get a structure similar to this:

.
├── __tests__
│   ├── App-test.js
├── android
├── ios
├── node_modules
├── .buckconfig
├── .eslintrc.js
├── .flowconfig
├── .gitattributes
├── .gitignore
├── .prettierrc.js
├── .watchmanconfig
├── App.js
├── app.json
├── babel.config.js
├── index.js
├── metro.config.js
├── package.json
└── yarn.lock

Some of the most popular mobile apps were built with the React Native framework. You probably have a few installed on your own smartphone. Here’s how the world’s most innovative brands use React Native (+5 great examples)

Structuring the pillars

We will define a structure for our project to grow efficiently and make its maintenance easier.

Our first step will be to define the directory structure within `src` (Source). This directory will contain all major project files.

Let’s create the following initial structure for our project:

.
├── src
│   ├── assets
│   │  ├── fonts
│   │  ├── images
│   ├── components
│   │  ├── atoms
│   │  ├── molecules
│   │  ├── organisms
│   ├── navigations
│   ├── scenes
│   ├── styles
│   ├── utils
│   ├── index.js

Right now you might be wondering why there are so many folders and files, but don’t worry, further on the post we’ll go over their purpose and how important each one of them is.

Enabling the use of the alias

To simplify the require/import of paths in our project, we must configure directory aliases. So let’s install the following packages:

$ yarn add -D eslint-import-resolver-babel-module@^5.1.0 
eslint-plugin-import@^2.18.2 babel-plugin-module-resolver@^3.2.0

After installing the dependencies, let’s configure the .babelrc:

.babelrc

{
  "plugins": [
    [
      "module-resolver",
      {
        "cwd": "babelrc",
        "root": ["./src"],
        "extensions": [".js", ".ios.js", ".android.js"],
        "alias": {
          "_assets": "./src/assets",
          "_components": "./src/components",
          "_atoms": "./src/components/atoms",
          "_molecules": "./src/components/molecules",
          "_organisms": "./src/components/organisms",
          "_navigations": "./src/navigations",
          "_scenes": "./src/scenes",
          "_services": "./src/services",
          "_styles": "./src/styles",
          "_utils": "./src/utils"
        }
      }
    ]
  ]
}

Edit the .eslintrc.js file to avoid lint errors when using the new alias:

module.exports = {
  root: true,
  extends: '@react-native-community',
  plugins: ['import'],
  settings: {
    'import/resolver': {
      node: {
        paths: ['src'],
        alias: {
          _assets: './src/assets',
          _components: './src/components',
          _atoms: './src/components/atoms',
          _molecules: './src/components/molecules',
          _organisms: './src/components/organisms',
          _navigations: './src/navigations',
          _scenes: './src/scenes',
          _services: './src/services',
          _styles: './src/styles',
          _utils: './src/utils',
        },
      },
    },
  },
};

Read more about alias setup at Babel Plugin Module Resolver.

Enable editors to alias autocompletion

Create the jsconfig.json file and use the same alias that was defined in .babelrc. Check it out below:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "_assets": ["src/assets/*"],
      "_components": ["src/components/*"],
      "_atoms": ["src/components/atoms/*"],
      "_molecules": ["src/components/molecules/*"],
      "_organisms": ["src/components/organisms/*"],
      "_navigations": ["src/navigations/*"],
      "_scenes": ["src/scenes/*"],
      "_services": ["src/services/*"],
      "_styles": ["src/styles/*"],
      "_utils": ["src/utils/*"]
    }
  }
}

Once you have edited it, it’s time to test the alias. Let’s edit our `src/index.js` file by adding a test component as follows:

import React from 'react';
import {View,Text} from 'react-native';

const App = () => (
  <View>
    <Text>Hello World</Text>
  </View>
);

export default App;

Now in our index.js in the project root we will import the App component as follows:

import App from './src';

This way you will have your alias set up working on your project. \o/

Atomic Components

For a better understanding of atomic system/components I indicate the reading

Atomic Design with React.

We will not dive into the concepts of atomic, only the organization we have chosen to use in this project. 

– Atoms – The smallest possible components, such as buttons, titles, inputs or event color pallets, animations, and fonts.

– Molecules – They are the composition of one or more components of atoms.

– Organisms – The combination of molecules that work together or even with atoms that compose more elaborate interfaces.

Remembering the directories we use to organize your components:

.
├── src
│   ├── components
│   │  ├── atoms
│   │  ├── molecules
│   │  ├── organisms

In each component directory, we have an index.js file that exports the specified category.

Let’s create a component called HelloWorld in src/atoms to understand the idea:

src/atoms/hello-world.js

import React from 'react';
import {Text} from 'react-native';

const HelloWorld = ({name}) => <Text>Hello World {name}!</Text>;

export default HelloWorld;

We export as follows: 

src/atoms/index.js

export {default as HelloWorld} from './hello-world';

Now we can use this component in src/index.js:

import React from 'react';
import {HelloWorld} from '_atoms'; 

const App = () => <HelloWorld name="Helder Burato Berto" />;

export default App;

Note: The App.js in the project root can be removed, it will no longer be used.

Our Scenes

I have a habit of dividing every application screen as a scene and so each one has its directory.

We will define some scenes that will not be used this time, and then we will configure these navigations using the created screens.

.
├── src
│   ├── scenes
│   │  ├── login
│   │  │	 ├── index.js // LoginScreen
│   │  ├── home
│   │  │	 ├── index.js // HomeScreen
│   │  ├── about
│   │  │	 ├── index.js // AboutScreen

At the Login screen, we will add a navigation button to go to the Home screen. See below:

import React from 'react';
import {SafeAreaView, Text, TouchableHighlight} from 'react-native';

const LoginScreen = ({navigation}) => (
  <SafeAreaView>
    <Text>Screen: Login</Text>

    <TouchableHighlight onPress={() => navigation.navigate('Home')}>
      <Text>Go to home</Text>
    </TouchableHighlight>
  </SafeAreaView>
);

export default LoginScreen;

Note: The navigation object will be available on all screens that are surrounded by the navigator object.

Ways of Navigation

In this step, we will need to add some new dependencies to the project. See below:

$ yarn add react-navigation@^4.0.0 react-navigation-stack@^1.5.3 
react-navigation-tabs@^2.4.0 react-native-gesture-handler@^1.4.1 
react-native-reanimated@^1.2.0

You can read more about it here.

In our application, we will have two types of navigation.

In the Login screen, we will have Stack navigation type and in the rest of the app we will have Tab navigation type.

Note: This is just an example of navigation, not a pattern. If you need to use other types of navigation, you can create them at the src/navigations.

In the src/navigations directory we will define the following structure:

.
├── src
│   ├── navigations
│   │  ├── index.js            // RootNavigator
│   │  ├── auth-navigator.js   // AuthNavigator
│   │  ├── app-navigator.js    // AppNavigator

1. In the auth-navigator.js we will define the navigation type for the login screen:

import {createStackNavigator} from 'react-navigation-stack';

import LoginScreen from '_scenes/login';

const AuthNavigatorConfig = {
  initialRouteName: 'Login',
  header: null,
  headerMode: 'none',
};

const RouteConfigs = {
  Login:LoginScreen,
};

const AuthNavigator = createStackNavigator(RouteConfigs, AuthNavigatorConfig);

export default AuthNavigator;

2. In the app-navigator.js we will define the type of navigation to internal screens app:

import {createBottomTabNavigator} from 'react-navigation-tabs';

import HomeScreen from '_scenes/home';
import AboutScreen from '_scenes/about';

const TabNavigatorConfig = {
  initialRouteName: 'Home',
  header: null,
  headerMode: 'none',
};

const RouteConfigs = {
  Home:{
    screen:HomeScreen,
  },
  About:{
    screen:AboutScreen,
  },
};

const AppNavigator = createBottomTabNavigator(RouteConfigs, TabNavigatorConfig);

export default AppNavigator;

3. In the index.js we will define our RootNavigator merging the auth and app navigators:

import {createAppContainer, createSwitchNavigator} from 'react-navigation';

import AuthNavigator from './auth-navigator';
import AppNavigator from './app-navigator';

const RootNavigator = createSwitchNavigator(
  {
    Auth: AuthNavigator,
    App: AppNavigator,
  },
  {
    initialRouteName: 'Auth',
  },
);

export default createAppContainer(RootNavigator);

Now you can import the Navigator object into your src/index.js as follows:

import React from 'react';

import Navigator from '_navigations';

const App = () => <Navigator />;

export default App;

This way you will have simple and functional navigation.

Reusable Services

Not everything can be considered a component in React Native, a well-known approach used to create separate modules and in some cases containing business rules are the use of services.

Directory for creating services:

src/services

They can be shared with multiple screens and components in your project.

Commonly used to create services that make contact with external APIs and use the axios library that we mentioned at the beginning of the post.

Shared Styles

Based in CSS preprocessor we use some default files in our style structure:

.
├── src
│   ├── styles
│   │  ├── index.js        // Export all          
│   │  ├── colors.js       // Colors pallet
│   │  ├── mixins.js       // Mixins to use CSSinJS
│   │  ├── spacing.js      // Paddings, margins and scale
│   │  ├── typography.js   // Fonts types and sizes

index.js

import * as Colors from './colors';
import * as Spacing from './spacing';
import * as Typography from './typography';
import * as Mixins from './mixins';

export { Typography, Spacing, Colors, Mixins };

colors.js

export const PRIMARY = '#1779ba';
export const SECONDARY = '#767676';
export const WHITE = '#FFFFFF';
export const BLACK = '#000000';

// ACTIONS
export const SUCCESS = '#3adb76';
export const WARNING = '#ffae00';
export const ALERT = '#cc4b37';

// GRAYSCALE
export const GRAY_LIGHT = '#e6e6e6';
export const GRAY_MEDIUM = '#cacaca';
export const GRAY_DARK = '#8a8a8a';

mixins.js

import {Dimensions,PixelRatio} from 'react-native';

const WINDOW_WIDTH = Dimensions.get('window').width;
const guidelineBaseWidth = 375;

export const scaleSize = size => (WINDOW_WIDTH/guidelineBaseWidth) * size;

export const scaleFont = size => size * PixelRatio.getFontScale();

function dimensions(top, right = top, bottom = top, left = right, property){
  let styles = {};

  styles[`${property}Top`] = top;
  styles[`${property}Right`] = right;
  styles[`${property}Bottom`] = bottom;
  styles[`${property}Left`] = left;

  return styles;
}

export function margin(top, right, bottom, left){
  return dimensions(top, right, bottom, left, 'margin');
}

export function padding(top, right, bottom, left){
  return dimensions(top, right, bottom, left, 'padding');
}

export function boxShadow(color, offset = {height:2,width:2},
                           radius = 8, opacity = 0.2){
  return {
    shadowColor: color,
    shadowOffset: offset,
    shadowOpacity: opacity,
    shadowRadius: radius,
    elevation: radius,
  };
}

spacing.js

import {scaleSize} from './mixins';

export const SCALE_18 = scaleSize(18);
export const SCALE_16 = scaleSize(16);
export const SCALE_12 = scaleSize(12);
export const SCALE_8 = scaleSize(8);

typography.js

import { scaleFont } from './mixins';

// FONT FAMILY
export const FONT_FAMILY_REGULAR = 'OpenSans-Regular';
export const FONT_FAMILY_BOLD = 'OpenSans-Bold';

// FONT WEIGHT
export const FONT_WEIGHT_REGULAR = '400';
export const FONT_WEIGHT_BOLD = '700';

// FONT SIZE
export const FONT_SIZE_16 = scaleFont(16);
export const FONT_SIZE_14 = scaleFont(14);
export const FONT_SIZE_12 = scaleFont(12);

// LINE HEIGHT
export const LINE_HEIGHT_24 = scaleFont(24);
export const LINE_HEIGHT_20 = scaleFont(20);
export const LINE_HEIGHT_16 = scaleFont(16);

// FONT STYLE
export const FONT_REGULAR = {
  fontFamily: FONT_FAMILY_REGULAR,
  fontWeight: FONT_WEIGHT_REGULAR,
};

export const FONT_BOLD = {
  fontFamily: FONT_FAMILY_BOLD,
  fontWeight: FONT_WEIGHT_BOLD,
};

This is our basic style settings to structure our application.

This way you can import into any of your components the following Typography, Spacing, Colors, Mixins objects, which will have access to the functionality of each style object.

Extra: Custom Font

To enable custom fonts you need to create the react-native.config.js in the project root and set the directory where your .ttf files are as follows:

module.exports = {
  assets:['./src/assets/fonts/'],
};

After that, you should run the `react-native link` to link your fonts to the iOS / Android native code.

Defining Utils

We have the src/utils directory where we add all our utility/helper methods that can be shared across our entire project.

Whenever you come across situations where you get caught repeating code is a good situation to create a util/helper.

Wrapping up

I have been working with this format on the last React Native projects I worked on and I can say that it helped me a lot regarding the organization and development of the project.

This is just one way we found to be productive and better organized among our team, I hope it helps you too.

Feel free to comment below if you have any questions, I’ll be happy to help you.

Enjoy programming!

The repository of this example is available at ReactNativeCklExample.

References

– Why React developers should modularize their applications?

– How to better organize your React applications?

– How To Structure a React Native App For Scale

– How to structure your project and manage static resources in React Native

The post An efficient way to structure React Native projects appeared first on Cheesecake Labs.

Views dimension in Activity lifecycle 

One of the very basic Android concepts that we first learn is the Activity lifecycle. We understand that the onCreate() callback is where the UI should be declared and configured. Having this in mind, let’s say we have a View that for some reason needs a manual setup like this:

myView.layoutParams.width = myView.width / 2

This sets myView width based on its own width, this means that this code should run only once. You add it inside onCreate() right after setting content view, run the application but it doesn’t work as expected. myView had a width of zero and then your code just divided 0 by 2. So you think, maybe the view will be laid out in onStart(). You test it and again it doesn’t work. Maybe onResume() will work? Wait… what?! onResume doesn’t work either?! The next lifecycle step should be when the Activity is already running and you are still unable to finish the UI setup. What else can we do?

Ok, let’s be radical and try onWindowsFocusChanged(). Voilà, it works! You are happy and can go back to work. Suddenly your app goes to background and a phone call pops up, it’s your mom asking you to buy some bread on your way home. After the call ends, your app comes back to the foreground, as well as your frustration. myView has now half the width that it should, and you realize that onWindowsFocusChanged() was called again after the app came back to the foreground. 

We now know that for some reason there isn’t a lifecycle callback for when the activity UI is fully laid out, which is something that some stacks provide for us, such as on iOS. So the question is, when is a view fully laid out and drawn?

How Android draws the UI

An Activity layout is drawn upon the view hierarchy. From the image below, you can see that this hierarchy is a tree with two different nodes – ViewGroup and View.

ViewGroup is also a View, but it is a layout or container that can contain many children. Examples of ViewGroups are LinearLayout and ConstraintLayout. View is any other UI component. 

Each View has two different types of sizes: the measured width and height, which is basically how big it wants to be, and the width and height that are the actual dimensions they have after being laid out. The desired size cannot always be provided, e.g. a view could request a width larger than its parent’s width. 

Both measured and actual sizes are set in two steps: 

• Measure pass: each View has a desired size – a measured dimension that is basically how big it wants to be. The measure pass is a process that starts from the root View Group and goes in a top-down transversal way setting the measured width and height of each View based on requirements passed from parent to children. Each View returns to its descendants the desired dimension. When this phase is over, every View has both measured width and height set.
• Layout pass: also top-down transversal, each parent is responsible for positioning its children Views based on actual sizes, which are not always the measured sizes set on Measure pass – every View has a measured width and height.

After the layout pass finishes, the layout can finally be drawn by the OS. 

This is a very basic explanation, but it is enough to have an idea of how the draw process works. But when does it happen? The documentation states that it starts when the Activity receives focus, then let’s see it happening with a small code that I wrote. 

The code has a custom LinearLayout and TextView which I created just to override onMeasure(), onLayout()/layout() and draw() functions and add some logs to them. You can check it out in this Gist. 

Running it results in these logs:

1 onCreate() executed

2 onStart() executed

3 onResume() executed

4 LinearLayout: entering onMeasure(). Measured width: 0

5 TextView: entering onMeasure(). Measured width: 0

6 TextView: leaving onMeasure(). Measured width: 171

7 LinearLayout: leaving onMeasure(). Measured width: 171

8 LinearLayout: entering onLayout(). Actual width: 171

9 TextView: entering layout(). Actual width: 0

10 TextView: leaving layout(). Actual width: 171

11 LinearLayout: leaving onLayout(). Actual width: 171

12 onWindowFocusChanged() executed

13 LinearLayout: entering onMeasure(). Measured width: 171

14 TextView: entering onMeasure(). Measured width: 171

15 TextView: leaving onMeasure(). Measured width: 171

16 LinearLayout: leaving onMeasure(). Measured width: 171

17 LinearLayout: entering onLayout(). Actual width: 171

18 TextView: entering layout(). Actual width: 171

19 TextView: leaving layout(). Actual width: 171

20 LinearLayout: leaving onLayout(). Actual width: 171

21 TextView: draw() executed

We can perfectly see measure and layout passes happening from lines 1 to 11, with measured and actual sizes of both views going from 0 to 171. We can also notice that the two passes happen twice, once before onWindowFocusChanged()and again from lines 13 to 21, but TextView calls draw() only when the Activity gets focus. This means that the layout is indeed drawn only after the Activity receives focus, but the views are laid out before it.

Understanding this whole process is very helpful, but it’s still hard to know how to have a callback for when the entire screen is laid out.

Most common solutions

After doing a little research, you will probably find some solutions that people claim they work, which usually are:

• View.post(Runnable action): this can be used to send your UI setup code to the message queue. Adding this after calling setContentView() inside onCreate() usually makes your code run after the UI is laid out. But you don’t have much control of message queue, which means this approach is much more a workaround than an elegant solution that we know will always work.
• ViewTreeObserver.OnGlobalLayoutListener: with this listener, you can set up a code that will be executed when global layout changes happen in the whole view tree. There’s a nice article with its usage explained by Antonio Leiva. But in the article there’s also a tweet from Chris Banes where he explains that this approach is overkill because it is triggered when layout changes happened to any view in the tree, and even with some improvements, such as removing the listener after the first call, it’s not guaranteed that when the listener is called your view has already been laid out, i.e. it might not have width and height set yet.
• View.OnLayoutChangeListener: “Interface definition for a callback to be invoked when the layout bounds of a view changes due to layout processing.”This looks promising. It will be triggered only when a specific view is changed instead of the whole view tree. But what if at the time that this listener is added, this view is already laid out and then it never runs your code? In this case, we could make it run the code straight away. We could even write a Kotlin extension for this, right? Nah, no need, it’s already done and it’s in the Android Jetpack.

Android KTX and doOnLayout to the rescue

Android KTX is a library that is part of Android Jetpack and has a lot of useful Kotlin extensions. For our case, it has the View.doOnLayout() extension with a callback for when a view is laid out, and it also ensures that the callback runs even if the View has already been laid out and hasn’t requested layout. If you are wondering what’s the magic behind it, there isn’t. It uses View.OnLayoutChangeListener without any crazy logic, as you can see in the source code.

A lifecycle callback for when the entire layout is laid out

With doOnLayout() we have a callback for when a specific view is laid out, but what if you want a callback that is called when the entire layout is laid out? Well, we know that the root View is the last one to be laid out, so this means that by using doOnLayout() with the root View, it will be called when all other Views have already been laid out. There’s just a small problem: how to get the root View? 

To achieve this goal in a generic way, we could get the content view of top-level window decor using a base Activity class:

abstract class BaseActivity: AppCompatActivity() {

    protected open fun doOnRootViewLayout(action: () -> Unit) {

        val rootView = window.decorView.findViewById<View>(android.R.id.content)

        rootView.doOnLayout {

            action()

        }

    }

}

Unfortunately I couldn’t find much information about this approach and how safe it is, except an article explaining that this low-level layer can change in other Android versions or devices. Also on Android documentation there isn’t much information about android.R.id.content. 

My suggestion is to give an ID to the root view of your layout and use this view to call doOnLayout(), which also works with Fragments and custom views.

Wrapping up

We were able to understand when Views have dimensions set and are drawn. For some reason there is not a lifecycle callback for that, but at least we came up with a working solution using doOnLayout.

Working with Android is a mix of love and hate, we all know that. Sometimes very basic things are difficult to achieve or understand (and it is even harder to understand why they are not explained in the documentation). I hope this article helps you to diminish the hate moments caused by some Android flaws (although it might have added more questions than answers) and write a better code and UI without fear of all that obscurity that Android sometimes leaves to us.

References

https://developer.android.com/guide/components/activities/activity-lifecycle

https://developer.android.com/reference/android/app/Activity#onWindowFocusChanged(boolean)

https://developer.android.com/guide/topics/ui/how-android-draws

https://developer.android.com/reference/android/view/View.html#post(java.lang.Runnable)

https://developer.android.com/reference/android/view/ViewTreeObserver.OnGlobalLayoutListener

https://antonioleiva.com/kotlin-ongloballayoutlistener/

https://developer.android.com/reference/android/view/View.OnLayoutChangeListener

https://developer.android.com/jetpack/

https://developer.android.com/kotlin/ktx

https://developer.android.com/reference/kotlin/androidx/core/view/package-summary#doonlayout

https://android.googlesource.com/platform/frameworks/support/+/android-room-release/core/ktx/src/main/java/androidx/core/view/View.kt

https://android-developers.googleblog.com/2009/03/window-backgrounds-ui-speed.html

https://developer.android.com/reference/android/R.id#content

The post Understanding when and how Android Views have dimensions set appeared first on Cheesecake Labs.

There are great articles out there about Product Thinking, like this one, but no canvas that brings together all the main questions Product Thinking focuses on.

With that being said, I took a stab at it and created one (there is a tiny possibility others are looking for something like this but never found it).

The result you can check below:

The Product Thinking canvas tackles user first (problem + target audience) followed by job to be done (vision + what you can do with our product + strategy) and finally the goals to be achieved and which features will ensure the product meets them.

The heart of the canvas is: what you can do with our product because this sentence impacted me profoundly:

“Here’s what our product can do” and “Here’s what you can do with our product” sound similar, but they are completely different approaches.

— Jason Fried (@jasonfried) November 13, 2013

As an example to materialize this sentence, we can state that Uber is not providing an app; it’s providing the possibility of connecting riders and drivers, anywhere, anytime.

Along with the fact that Product Thinking focuses on resolving real problems, it also opens up the opportunity to build products that can help us faster, that have the ability to know us more and surprise us whenever possible.

I hope this post inspires you to research further about Product Thinking and empower you to build more human-centered, product-oriented and business-relevant products.

The post How I created the Product Thinking Canvas appeared first on Cheesecake Labs.

Here at Cheesecake Labs we care a lot about how the projects are structured. This is very important when working in teams in the same codebase. This way everybody codes in the same style. Keeping code readable for everybody during the whole project.

Android Architecture Components brought a new way to connect the views to the backend of Android projects: the “ViewModel”. The name explains itself. It’s an intermediary layer that connects the View (UI) to the Model (Business logic, APIs and persistency). It makes the structure of Android projects more simple to understand and it is also a good way to keep view and business logic decoupled, organized and easy to test.

MVVM is not mentioned in Google’s documentation, but the implementation of the Android ViewModels fits very well in the MVVM design pattern. So that’s what we decided to use.

MVVM worked so well in Android projects that we decided to use it in iOS projects too. And the results have been very good so far.

MVVMC

ViewModel is not a new concept. It’s the main part of the MVVM design pattern that was first introduced in 2005 by Josh Gossman in this post at Microsoft’s blog. It was created to be used as a design pattern in .NET applications, but of course we can use it anywhere – including Android and iOS projects. Each platform has its implementation particularities, so for iOS we are using the way the Runtastic team introduced in this blog post. The MVVMC.

MVVMC is made of five main layers:

View

This is the UI. It shows information to the user and tells the ViewModel about User actions. It should not know about ViewModel implementation, so the ViewModel can be unit tested with a “mocked” view. There are a lot of ways to connect these layers. Here is an example using simple delegates:

class RocketLaunchViewController: UIViewController {
     var viewModel: ArticlesListViewModel?   
     
     override func viewDidLoad() {
          super.viewDidLoad()
          viewModel?.onViewDidLoad()
     }
     
     @IBAction func didTapLaunchButton(_ sender: Any) {
          viewModel?.onLaunchButtonTapped()
     }
}
 
extension RocketLaunchViewController: RocketLaunchViewDelegate {
     func showSuccessMessage() {
          //Show success message
     }
}

Model

The model is an abstraction of the app data. Usually we define entities that represents the objects and business logic that define how these entities relate to themselves. Each project has a particular model structure that can be fetched from an API, persisted in the database, sent to a Bluetooth device, etc… Model layer is shared between all modules of the project, so it’s important to keep this layer consistent and safe.

ViewModel

This is the glue that makes all parts working together. The ViewModel is responsible for telling the View what should be shown to the user and to respond to whatever the user does in the UI. The ViewModel uses an Interactor to access the model layer and the Coordinator to communicate to other modules. Here is a small example:

protocol RocketLaunchViewDelegate: class {
     func showSuccessMessage()
}
 
class RocketLaunchViewModel {
     weak var view: RocketLaunchViewDelegate?
     var interactor: RocketLaunchInteractor?
     var coordinator: RocketLaunchCoordinator?

     func onViewDidLoad() {
          interactor?.fetchRockectData() { result in
               if result.status == .success {
                    self.view?.showSuccessMessage()
               }
          }
     }

     func onLaunchButtonTapped() {
          coordinator?.showLaunchProgressModule()
     }
}

Interactor

The interactor exposes the model layer to the ViewModel. Access to Database, API requests and other data that are external to the current module should be asked to the interactor by the ViewModel. Usually we create data access that is shared between all modules, like an API Manager, or Database Manager that concentrates logic that keep the data consistent. Interactor is the part that should communicate to these managers.

Coordinator

This part of the MVVMC pattern was added to handle communication between MVVMC modules. It is the way ViewModel uses to communicate and initiate other modules. This is also used to assemble a new MVVMC module. Code tells more than words, so:

class RocketLaunchCoordinator {
     var viewController: UIViewController?
     
     func initModule() -> UIViewController {
          let interactor = RocketLaunchInteractor()
          let viewModel = RocketLaunchViewModel(coordinator: self, interactor: interactor)
          let viewController = UIStoryboard.loadViewController() as RocketLaunchViewController
          viewController.viewModel = viewModel
          return viewController
     }
      
     func showLaunchProgressModule() {
          let viewController = LaunchProgressCoordinator().initModule()
          viewController?.presentViewController(viewController, animated: true)
     }
}

That’s it!

MVVM is simple and we can maintain a design pattern that is similar in both mobile platform. It defines how things connect and keeps all the code in its place according to what they should be doing.

Is it better than VIPER?

Yes – this is my short answer!

The long explanation is: for some time VIPER has been our design pattern to be used as the default structure of the modules of mobile apps at CKL. VIPER has brought established solutions to some common issues we have being through. It decouples things, so they can be tested. And defines responsibilities for every layer, so we know where to put code, avoiding the famous Massive View Controllers.

So, what’s wrong with it?

VIPER has too many layers. This started to become a problem. Every new module needs a big set of classes, even when the module is a simple one, like a login page. There are too many things we need to plug and a lot of abstraction layers to understand.

MVVM brings all the testability and decoupling we need in a smaller and more simple to understand pattern. MVVM core has only 3 layers. And the name of these layers explain themselves. Of course we added Coordinator and Interactors to the set. But the core of the pattern is simple and the same for both platforms.

Also, I don’t like snakes. ????

References

• https://medium.com/developermind/blurring-the-lines-between-mvvm-and-viper-dcb3dc9815ac
• https://blogs.msdn.microsoft.com/johngossman/2005/10/08/introduction-to-modelviewviewmodel-pattern-for-building-wpf-apps/
• https://developer.android.com/topic/libraries/architecture
• https://www.runtastic.com/blog/en/mvvmc-adapting-the-mvvm-design-pattern-at-runtastic/
• https://blog-stg.cheesecakelabs.com/blog/ios-project-architecture-using-viper/

The post MVVM in iOS appeared first on Cheesecake Labs.

Sprint Retrospective is an opportunity for the team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

I like to think that when we start the retrospective the team is feeling like: “Yay! How are we going to tackle retrospective today? I’m so excited!” instead of “Oh okay, we’re doing that again.”

Interested to have a big picture of what’s happening inside the team? Let’s get to it!

About Team Radar

Team Radar is very similar to the Competency Wheel. Radars are great because it presents data in a visual way, helping the teams understanding the present moment through a variety of topics. Since it is a visual tool, you can easily map “hot” topics and open the channel to start the discussions around it.

Prep work

I’ve created a template with the topics I selected for this first Radar and printed copies for all the team. I selected some soft topics (collaboration, partner contact, fun) and mixed it up with technical topics (technical debt, definition of done, refactoring, scrum and design).

I also created a spreadsheet to record each one of the team’s inputs and quickly have the ability to assess the most important topics to discuss.

Conducting Team Radar

Start of retrospective

I’ve started the retrospective by sharing with the team what we would be doing and created a shared understanding regarding each one of the listed topics. We defined what would represent the smallest and highest values for each one of them.

Filling out the team radar

Using Radar’s printed version I asked the team to individually rate the topics based on what we defined for each one of them. We’ve used the scale from 1 to 10 and everyone marked down their answers. Refactoring and Technical Debt were the only ones that the smaller the value the better (less refactoring/rework, less technical debt for whatever reason).

Connecting the dots

Once everyone was done with rating the topics, I’ve asked them to connect the dots from the eight axis. Now everyone had their individual radar. It was so fun because some of them used their creativity to fill the radar out as you can check below:

Taking it to the next level

We then transposed all this rich data into the spreadsheet and the result was the team’s radar as follows:

I displayed the team Radar on a big screen and the conversation about the most relevant topics started. We documented the key takeaways and generated some important action items from there.

Conclusions

The team had fun and I did too! It generated a lot of great discussions about the defined topics. The team also had the chance to propose some other topics to be discussed next time – this means we will do another radar retrospective for sure.

References

Retrospective: Do the team radar

Retrospective: Using the Team Radar

The post The perks of a Team Radar Retrospective appeared first on Cheesecake Labs.

We are used to write data using tables, to relate them through primary keys and, by looking directly at the data, you only see IDs. Graph databases were designed mainly so that this doesn’t happen. Its purpose is for you to have a complete understanding when looking at the data.

First of all, to understand an advantage of graph databases, it’s very good to know a few concepts that reinforce the idea of software close to the business rules. For that, it is worth reading Domain-Driven Design, where the model should be as close as possible to the business.

In Neo4j, that is done with Cypher: a declarative SQL-inspired language for describing patterns in visual graphs using an ASCII syntax. It allows us to state what we want to select, insert, update or delete from our graph data without requiring us to describe exactly how to do it.

To be more practical, mind the example below, where the same “query” is implemented with SQL and Cypher.

SELECT f.* FROM students s
INNER JOIN person p
ON p.id = s.person_id
INNER JOIN friend f
ON f.friend_from_id = p.id
WHERE s.id = 45
ORDER BY p.name

MATCH
(student :Student)-[FRIEND]->(person :Person)
WHERE student.id = 45
RETURN person
ORDER BY person.name

Above there’s a “query” to search for a specific student’s friends, where in the traditional mode (SQL) we need to better understand the database structure and know how they relate, causing a greater use of “JOINS”. In Cypher relations are more intuitive for reading.

Graph databases are a more natural way of storing the data. You don’t have to worry about tables and foreign keys and it keeps everything within two simple concepts: nodes and relations. Each node or relation can have its attributes and labels of identification, a way to categorize the data.

To make it easier to understand, let’s map a school in a simple way, where we have students, teachers and courses. How would a diagram represent this? Would you do it in a graph database? It is actually simpler than you think! Just draw it:

Now, hands-on!
You can install Neo4j on your computer or do it using Docker:

image: neo4j:3.4.5
ports:
  - "7474:7474"
  - "7473:7473"
  - "7687:7687"

Don’t forget to follow the rules and nomenclature recommendations.

Creating our first nodes:

CREATE (s)-[k:KNOWS]->(t), (t)-[ts:TEACHES]->(c), (s)-[e:ENROLLED]->(c)
CREATE (user1:Person:Student { name: "Natam" })
CREATE (user2:Person:Teacher { name: "Natalia" })
CREATE (course:Course { title: “Math” })

Now let’s relate them:

MATCH (s:Student {name:"Natam"}), (t:Teacher {name:"Natalia"}), (c:Course {title:"Math"})

Now that we have our data, we need to consult it. Let’s do this?

MATCH (n) RETURN n

This command will return an overview of your graph. You can apply more filters and conditions to your “query”. Check this out: https://neo4j.com/docs/developer-manual/current/cypher/clauses/where/

Conclusion, but already?

Yes! The purpose of this post is for you to get to know this incredible technology and how basic is its structure. If you found it interesting and want to learn more about it, try modeling applications you already know using Neo4j. I’m sure you’ll be even more surprised!

I will leave a few links in case you want to know more concepts related to this technology.

REFERENCES

Semantic Web – Wikipedia

The Semantic Web is an extension of the World Wide Web through standards by the World Wide Web Consortium (W3C). The…en.wikipedia.org

Ontology – Wikipedia

The post Starting with Graph Databases: A Quick look into Neo4j appeared first on Cheesecake Labs.

In our universe, a lot of tools were created and given as gift to the rulers of the Earth. If we focus on technology, more precisely in mobile metrics, we can say that there are Three tools for the Analytics kings under the sky – and they are as powerful as the elven rings.

Let’s say that you had a mobile app idea, started to work on it, and finally started the development process. Everything is running ok and the screens looks gorgeous, but you feel that something’s missing: Data.

You may know how much users downloaded the app or started a session, but there is no info about which screen they opened or which button they clicked. Maybe you are trying to create a better search performance, but, in fact, the users are more attracted to the timeline than to the search, which is used by only 5% of your users. How to know about it? Metrics.

But how and where should the data be sent? How much will it cost?
I researched and tested three tools: Google Analytics, Firebase and MixPanel.
I’m glad to show you about them in the next lines, giving them a personal score and hoping to help you with this decision.

Google Analytics

The Ring Tool of Water, of preservation and protection. Some may say it looks more like a star than a ring tool.

You have probably heard about or even used Google Analytics (GA). It is the oldest one among the three tools, forged launched in 2005 and is widely used. If you mention that your product doesn’t have metrics implemented, you can hear something like “Not even Google Analytics?”.

It was the first platform that I ever used to metrify mobile apps. The setup is easy, the docs are great and it works very well. It also has some out of the box features, like screen funnels, and even allows you to create custom dashboards.

You can also set Custom dimensions to the tracked events, so you can add more info to it, like a search query into the performed search event. A setup is needed to use this feature, but there’s a good doc for it.

There is a Real-Time view that allows you to see tracked events “live” and it works very well, with very little delay, but you can’t check the custom dimensions in this view.

So if you want to check the custom dimension for a tracked event you need to wait for it to be “flushed” and be available at the Behavior session, which can take a few hours to happen.

You can show your data in a great way for your team with Google Data Studio.

Score: 7

GA is a great tool. There are some features in Beta version, so it’s still in development and maintenance, but there are some reasons for this score.
The setup tutorials recommend you to use Firebase as the tracking solution for Google Analytics.

Also, for you to extract more info, like custom funnels and formulas, that are not an out of the box feature, you have to study it deeper. Fortunately, Google offers online courses for it.

Good to mention that it’s free if you are not an enterprise with high traffic volume (otherwise it could cost $150,000/year USD).

Firebase

The Ring Tool of Fire, that gives hope and helped Gandalf to fight with the Balrog.

Firebase was forged founded in 2011 and acquired by Google in 2014. It is a HUGE platform and has a lot of functionalities, like authentication, database, storage, notifications, A/B testing, analytics and more.

If you already use Firebase for anything else, like notifications, some data will already be there, like the Screens and infos related to the app, like First Opens and App Remove.

Firebase’s Dashboard is similar to the GA’s Home, but there is an easier access to create funnels and perform some other analysis.
In contrast, there is no screen funnel like the GA has.

Firebase has many default events, like Search, Sign Up and Login. If you want to know more about them, their doc is great.

You can send Parameters with the event to add more info to it, like the GA’s Custom Dimensions, but they have a restricted view.

Firebase allows you to link your data to other platforms, like BigQuery, that can perform analysis even more in details and can be used to Google Data Studio, but you need to upgrade your account for it.

Firebase has a StreamView that shows you where in the globe people are using your app right now, allowing you to check out user snapshot’s in real time. Also, the tracked events are “flushed” to the Events dashboards in minutes.

Score: 8

Firebase is the Google recommended tool, allowing more in deep analyze of your data.
The other features are a great point for Firebase, allowing you to create an app using only Firebase as the server with the database and authentication functionalities.
The Dashboard is more punctual, but the lack of the screen funnel is a negative point.
The event names pattern are also a negative point, and having in mind that linking with BigQuery is only possible to do with an upgraded account. It may require you a greater effort to present the data to, for example, the marketing team.

The Firebase Analytics is totally free, but other tools of the platform may need an upgrade, and there are 3 pricing plans.

MixPanel

The Ring Tool of Air, may be considered the mightiest of these three bands, possessing the power to heal and to preserve.
Forged Founded in 2009, MixPanel is a great platform that also has functionalities like notifications and A/B testing, but its main focus is on analytics.

Their doc is not that good, the Android samples are all in Java (at Cheesecake Labs we use Kotlin), some screenshots are outdated, but it could be worse.
With MixPanel you create your own dashboard, including the reports you want to see there and allowing you to send email digests of this info for whoever you want.

The additional infos of the tracked events are called Properties, and are sent to the SDK as a JSON object with key value pairs.

The Analysis session has a lot of tools that are very simple to setup and with results that are easy to understand, making the analysis of your data the best possible.

Insights is a report that can be customized for event and period of time. I consider this the “default events view”.

To segment the analysis of an event by a dimension, that is what Segmentation is for, and the results can be very interesting.

The Live View works very well, taking only seconds to show the events, and after you see the data there, you can already use them to your analysis.

Formulas allow you to understand the relation between events.

Funnels are the way to know how many users don’t complete a sequence of actions (e.g. sign up, agree with terms and conditions, and complete a profile), and MixPanels has a great result view.

Retention is the traditional check of users coming back to the app.

The last of this session, but not least, Signal, helps to understand actions that drive users to convert or retain.

MixPanel also has a Users session to Explore, Cohort and Predict. Explore give you access to the user’s properties (device related), including all the tracked events and an action where you can interact directly with e-mail or notification. At Cohort you can group users that have a similar behavior in a period of time. While Predict tells you which users are likely to convert based on what they do and who they are.

The Take Action session is for Campaign, Messaging and A/B testing.

Score: 9

The layout and the way the results are shown are the great part of MixPanel. Everything is crystal-clear.
It’s also the faster tool to check out the tracked events.
The tools to analyze your data are right in front of you, with video tutorials to help you and, if you still have some doubts, there is a Support chat in the bottom right corner.
The most negative point of MixPanel comparing to GA and Firebase is related to the screen tracking, since it’s not an out of the box functionality.

There are also 3 pricing plans, starting from Free going to Startup, that allows more members to the project and more time for the data history for $999/year, ending at Enterprise, with unlimited data history and premium support, and to get to know the price you need to contact them.

Summing Up

In the end, it’s up to you, but if you question me about metrics at Prancing Pony, I would say something like this:

If you are a data scientist of a huge app that contains a lot of traffic with a lot of data to analyze and the price is not a problem, I would say to you to go with MixPanel. It probably will make your life easier, not only understanding your users and your data, but presenting it to your teammates too. Probably if this is your case, the price of the platform will not be an obstacle.

But in the case that the price really matters or if you don’t have that high traffic volume, I would like to suggest you to go with Google Analytics having in mind the Google Data Studio integration and the event names without a certain pattern, but you know, Firebase is the most up-to-date and I’m afraid of a depreciation of GA.

In other case, if your app is completely new and you don’t even have a Back-end developer for the database and authentication part, Firebase is the right platform for you.

Thanks and good analysis for we all!

The post Three Tools for the Analytics Kings Under the Sky appeared first on Cheesecake Labs.

Unfortunately, there are some situations when applying a migration by itself is not enough. What would you do if you needed to add a required field to an existing table? How about changing a many-to-many relationship to just a foreign key without losing pre-existing data? It may be painful and critical to make these changes without the right tool; that’s why we have Data Migrations! In this post I’ll use data migrations to approach these two scenarios.

First Scenario

Let’s say you have to design a tracking system for a company that sells computers. This system should register the computers bought by each customer. We can migrate the following models:

GitHub

from django.db import models

# Create your models here.
class Client(models.Model):
    name = models.CharField(max_length=255)

class Computer(models.Model):
    brand = models.CharField(max_length=255)
    bought_by = models.ForeignKey(Client, related_name='computers')

Now, for some reason, we’ll need to fetch a list with the information of how many computers each customer has bought. Somehow, this is incredibly expensive to compute and your queries would take extra time if you use annotations with a Count aggregation. One possible solution would be to add a column on the Customer model to keep track of the amount of computers sold to that specific customer. To keep data integrity, we’ll make this field required for all new customers.

To provide the initial data to  this new computed required field on your model, you can use a data migration. It basically works by executing a custom function in between schema migrations.

Step 1. First we add the field to our model as a non-required field and run the makemigration and migrate commands:

GitHub

from django.db import models

# Create your models here.
class Client(models.Model):
    name = models.CharField(max_length=255)
    bought = models.IntegerField(null=False)

class Computer(models.Model):
    brand = models.CharField(max_length=255)
    bought_by = models.ForeignKey(Client, related_name='computers')

Step 2. Then, we’ll add a blank migration file; here we’ll add the custom function to perform the data migration. We use the following command:

python manage.py makemigrations --empty store --name prepopulate_bought_field

Note: store is the Django app you’re working on and you can use the –name parameter to get more informative names for your migrations.

Step 3. Now you’ll need to write the function for this migration (this is called the forwards function):

GitHub

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations

def add_bought(apps, schema_editor):
    Client = apps.get_model('store', 'Client')
    for c in Client.objects.all():
        c.bought = c.computers.count()
        c.save()

class Migration(migrations.Migration):
    dependencies = [
        ('store', '0002_client_bought'),
    ]

    operations = [
        migrations.RunPython(add_bought, reverse_code=migrations.RunPython.noop)
    ]

Note that for using our Customer model, we can’t just simply import it; this would get the most recent model that could be already changed by someone else (e.g. adding a field). To avoid this, we use apps.get_model to fetch the current migration version.

This operation can also have a rollback (or reverse function) if you want or need to, simply add it as the RunPython’s parameter reverse_code – see more here. In this example, we use migrations.RunPython.noop to make the migration reversible without executing any code on the rollback.

Step 4. After computing and storing all data, we can change the bought field to required in our model by setting its null property to False (it’s also possible to  do this change on the data migration file if you want to save a migration). This step will generate another migration and you may see something like this in your screen after running makemigrations command:

You are trying to change the nullable field 'bought' on customer to non-nullable without a default; we can't do that (the database needs something to populate existing rows).
Please select a fix:
1) Provide a one-off default now (will be set on all existing rows with a null value for this column)
2) Ignore for now, and let me handle existing rows with NULL myself (e.g. because you added a RunPython or RunSQL operation to handle NULL values in a previous data migration)
3) Quit, and let me add a default in models.py
Select an option:

You only need to select 2 because that’s exactly what you did: you added a RunPython operation to handle null values in a previous data migration.

Second Scenario

Now, say we have an address list and we thought it would be nice to have a many-to-many relationship so we wouldn’t need to repeat rows in address table. A few days later you realize that when users change their addresses, it changes for other users with the same address too. You now want to store a full address for each customer, even if it comes with some cost.
The current state of our models looks like this:

GitHub

from django.db import models

# Create your models here.
class Address(models.Model):
    street_name = models.CharField(max_length=255)

class Client(models.Model):
    name = models.CharField(max_length=255)
    addresses = models.ManyToManyField(Address)

For this data migration, we’ll need an intermediary model to store addresses data before deleting it! We change our models to something like this:

GitHub

from django.db import models

# Create your models here.
class Address(models.Model):
    street_name = models.CharField(max_length=255)

class Client(models.Model):
    name = models.CharField(max_length=255)
    addresses = models.ManyToManyField(Address)

class NewAddress(models.Model):
    street_name = models.CharField(max_length=255)
    client = models.ForeignKey(Client)

Similarly to what we’ve done in the previous scenario, we create a migration and write write a custom function (or forwards_func) to move all data that was store on Address table to NewAddress table. It looks like this:

GitHub

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import migrations, models
import django.db.models.deletion

def migrate_data(apps, schema_editor):
    Client = apps.get_model('address_book', 'Client')
    NewAddress = apps.get_model('address_book', 'NewAddress')

    for c in Client.objects.all():
        for a in c.addresses.all():
            NewAddress.objects.create(street_name=a.street_name, client=c)

class Migration(migrations.Migration):

    dependencies = [
        ('address_book', '0001_initial'),
    ]

    operations = [
        migrations.CreateModel(
            name='NewAddress',
            fields=[
                ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')),
                ('street_name', models.CharField(max_length=255)),
                ('client', models.ForeignKey(on_delete=django.db.models.deletion.CASCADE, to='address_book.Client')),
            ],
        ),
        migrations.RunPython(migrate_data, reverse_code=migrations.RunPython.noop)
    ]

We can now remove our old Address model, then run makemigrations and rename your NewAddress model to Address. It’s important to run makemigrations in between these two operations, otherwise Django will treat NewAddress as if it was the old Address.

Note that even using migrations.RunPython.noop, this migration is not reversible because we’re deleting and renaming models. If you need it to be reversible, you should write another custom function that does the rollback.

Conclusions

These operations can be very harmful to your data if used improperly, so it’s always a good idea to have a database dump before doing something like this in production. These scenarios we used as example are a bit silly, but it’s enough to get the idea of how to apply data migrations to solve data consistency issues.

You can also make fixtures for loading some initial data to your apps or just importing a text file on any of your data migrations and running a forwards function to get them in your database.

As Sir Oliver Wendell Holmes would say, The young man knows the rules, but the old man knows the exceptions. So if you know any exceptions, please let us know, help is very much appreciated.

The code used in this blogpost is available on GitHub.

Good references

• https://realpython.com/blog/python/data-migrations/
• https://docs.djangoproject.com/en/2.0/topics/migrations/#data-migrations
• https://simpleisbetterthancomplex.com/tutorial/2017/09/26/how-to-create-django-data-migrations.html

The post Keeping data integrity with Django migrations appeared first on Cheesecake Labs.