ScreenCloud

screencloud

Linking New York and Dublin via a livestream video portal is actually a stroke of genius. The two cities, separated by an ocean, share elements of history and culture, making them seemingly obvious bedfellows in this artistic endeavor. Created by a Lithuanian artist, and backed by the local councils of both Dublin in Ireland and New York City, the project was designed to foster a unique digital connection and bridge the sea. And while it has done that admirably, the headlines have focused mainly on some of the NSFW behavior exhibited by some of the residents of each city. But while the new livestream portal between the two cities presented a mixed bag of very human behavior, it has also shown another way that technology can be used to bridge gaps. A spokesperson for the Dublin City Council said, “The overwhelming majority of interactions are positive. We have seen families and friends unite, dancing moves being shared as well as new friendships being made. There was even a successful marriage proposal.” And despite the fact that the New York/Dublin link has seen some slightly scandalous headlines, this isn’t actually the first portal. The first cross-city portal link was between Lublin in Poland and Vilnius in Lithuania and has widely been seen as a success. In fact, there are other portals planned soon, with another connection in Brazil, according to the Portals organization website. So far, cool idea - barring some very human issues. But could this be the start of a new way of using digital tools for connecting and communicating? Using Screens to Communicate We’ve all grown used to jumping on a Zoom call, sharing Insta updates, dropping some WhatsApp messages, and even, shock horror, maybe actually calling someone. But the livestream portal suggests that we don’t even need to schedule a call anymore - we could create our own little windows into the world. Mark McDermott, CEO of ScreenCloud, has long been espousing the benefits of connected screens. “We’ve grown used to seeing screens everywhere, often just selling us stuff, reminding us not to leave our luggage lying around or sometimes just blank with an input error message. But portals can be a really good way to use these screens to communicate in a more fluid manner.” As he says, there are a number of ways he sees the potential use cases for this type of technology. “Obviously New York and Dublin are two big global cities. But a portal can be used to connect anything from different business locations, college campuses, events. They could even add a connection for twinned cities - a similar approach to the New York/Dublin Livestream portal, but perhaps with less potential for scandal.” An example of this within a business setting could be using a live stream portal setup in the breakrooms of different branch offices. This then means that distant work colleagues could chat casually over the water cooler, even if they’re in different cities… The same opportunities could be used for school or college campuses, research centers, multi-site events, or government offices. And the opportunity to have an ad-hoc chat over a livestream portal screen could mean less wasted time on meetings that could have been emails. Something that many of us are all too familiar with… If this sounds like it could be tricky to build, create and manage, actually it’s more simple than you might think. Especially when you factor in low-cost hardware and affordable software solutions. Use Cases for Two-Way Live Streaming Live streams are obviously nothing new. Webcams have been around since the internet began, and we’ve seen various platforms adopt live streaming to Q&As and webinars, gaming, and sports events. But two-way live streaming could change elements of the workplace, customer service, how we interact with local government, and even our friends and families! While an open channel to discuss with work colleagues in different locations might seem obvious, another opportunity in customer service could be just as important. Especially in an era where AI is being used to replace human interaction. A two-way livestream could connect shoppers to customer support via a location within a store. Or citizens could attend political rallies, government consultations, or parliamentary sessions from provincial offices, without needing to make a trip to parliament. As Mark McDermott from ScreenCloud points out, “The use cases for creating two way live streaming portals are potentially endless. It could also be an incredible tool for cooperation across different departments or hubs. For example if you have your researchers in one location and product team in another, rather than scheduling daily or weekly meetings, a live portal could facilitate real time collaboration.” What Do You Need to Create a Livestream Portal? The technology linking a livestream portal is actually quite simple and readily available using consumer-grade tech. All you need is a screen on each side with a live streaming connection via a tool such as YouTube Live, Twitch, or Zoom. Those looking for a more solid and permanent stream could also use a tool such as Open Broadcaster Software, which is an open-source live streaming solution. It would then be a case of connecting these dual streams to your display, either via a local hard drive or using a cloud-based digital signage software to stream. Of course, the cloud-based option frees up space, as most modern TVs feature integrated casting. As far as screens go, the choice is as broad as you want it to be. Whether it’s a standard smart TV or an interactive video kiosk. If you’re creating a break room portal, for example, screens connecting two offices, an inexpensive LCD TV would be perfect. For a more public installation, for example in a campus foyer, or at a music festival, you’d need a more hardwearing piece of equipment such as an OLED video wall or freestanding digital signage screen. But the portal has opened up a new way of thinking about how screens communicate. Where will they pop up next? Linking New York and Dublin via a livestream video portal is actually a stroke of genius. The two cities, separated by an ocean, share elements of history and culture, making them seemingly obvious bedfellows in this artistic endeavor. livestream video portal livestream video portal Created by a Lithuanian artist, and backed by the local councils of both Dublin in Ireland and New York City, the project was designed to foster a unique digital connection and bridge the sea. And while it has done that admirably, the headlines have focused mainly on some of the NSFW behavior exhibited by some of the residents of each city. But while the new livestream portal between the two cities presented a mixed bag of very human behavior, it has also shown another way that technology can be used to bridge gaps. A spokesperson for the Dublin City Council said, “The overwhelming majority of interactions are positive. We have seen families and friends unite, dancing moves being shared as well as new friendships being made. There was even a successful marriage proposal.” And despite the fact that the New York/Dublin link has seen some slightly scandalous headlines, this isn’t actually the first portal. The first cross-city portal link was between Lublin in Poland and Vilnius in Lithuania and has widely been seen as a success. Vilnius in Lithuania Vilnius in Lithuania In fact, there are other portals planned soon, with another connection in Brazil, according to the Portals organization website. Portals organization Portals organization So far, cool idea - barring some very human issues. But could this be the start of a new way of using digital tools for connecting and communicating? Using Screens to Communicate We’ve all grown used to jumping on a Zoom call, sharing Insta updates, dropping some WhatsApp messages, and even, shock horror, maybe actually calling someone. But the livestream portal suggests that we don’t even need to schedule a call anymore - we could create our own little windows into the world. Mark McDermott, CEO of ScreenCloud , has long been espousing the benefits of connected screens. ScreenCloud ScreenCloud “We’ve grown used to seeing screens everywhere, often just selling us stuff, reminding us not to leave our luggage lying around or sometimes just blank with an input error message. But portals can be a really good way to use these screens to communicate in a more fluid manner.” As he says, there are a number of ways he sees the potential use cases for this type of technology. “Obviously New York and Dublin are two big global cities. But a portal can be used to connect anything from different business locations, college campuses, events. They could even add a connection for twinned cities - a similar approach to the New York/Dublin Livestream portal, but perhaps with less potential for scandal.” An example of this within a business setting could be using a live stream portal setup in the breakrooms of different branch offices. This then means that distant work colleagues could chat casually over the water cooler, even if they’re in different cities… The same opportunities could be used for school or college campuses, research centers, multi-site events, or government offices. And the opportunity to have an ad-hoc chat over a livestream portal screen could mean less wasted time on meetings that could have been emails. Something that many of us are all too familiar with… If this sounds like it could be tricky to build, create and manage, actually it’s more simple than you might think. Especially when you factor in low-cost hardware and affordable software solutions. Use Cases for Two-Way Live Streaming Live streams are obviously nothing new. Webcams have been around since the internet began, and we’ve seen various platforms adopt live streaming to Q&As and webinars, gaming, and sports events. But two-way live streaming could change elements of the workplace, customer service, how we interact with local government, and even our friends and families! While an open channel to discuss with work colleagues in different locations might seem obvious, another opportunity in customer service could be just as important. Especially in an era where AI is being used to replace human interaction. A two-way livestream could connect shoppers to customer support via a location within a store. Or citizens could attend political rallies, government consultations, or parliamentary sessions from provincial offices, without needing to make a trip to parliament. As Mark McDermott from ScreenCloud points out, “The use cases for creating two way live streaming portals are potentially endless. It could also be an incredible tool for cooperation across different departments or hubs. For example if you have your researchers in one location and product team in another, rather than scheduling daily or weekly meetings, a live portal could facilitate real time collaboration.” What Do You Need to Create a Livestream Portal? The technology linking a livestream portal is actually quite simple and readily available using consumer-grade tech. All you need is a screen on each side with a live streaming connection via a tool such as YouTube Live, Twitch, or Zoom. Those looking for a more solid and permanent stream could also use a tool such as Open Broadcaster Software , which is an open-source live streaming solution. Open Broadcaster Software Open Broadcaster Software It would then be a case of connecting these dual streams to your display, either via a local hard drive or using a cloud-based digital signage software to stream. Of course, the cloud-based option frees up space, as most modern TVs feature integrated casting. As far as screens go, the choice is as broad as you want it to be. Whether it’s a standard smart TV or an interactive video kiosk. If you’re creating a break room portal, for example, screens connecting two offices, an inexpensive LCD TV would be perfect. For a more public installation, for example in a campus foyer, or at a music festival, you’d need a more hardwearing piece of equipment such as an OLED video wall or freestanding digital signage screen. But the portal has opened up a new way of thinking about how screens communicate. Where will they pop up next?

Why the New York-Dublin Portal Marks a New Era in Communication 

Use , and to display real-time changes in an application. This is the main theme of today's blog. Streams Firebase Cloud Functions, FireStore Intro Hello and Welcome to the 12th of the Flutter App Development Tutorial Series. This is Nibesh from Khadka's Coding Lounge. We traveled a long way to be here. We created a , wrote a , made a made an , set up a connection with firebase , , and accessed s on firebase projects. splash screen theme custom app bar, authentication screen cloud and emulators authenticated users users’ location We'll pick right where we left off and toggle the favorite icon for temples. We'll use Firestore to store all the favorites list for each user's document in the " " collection. The Firebase Function will help us fetch the immediate list and update it. While Stream will provide the changes in real-time for users to see. You can find the source code so far . last time users here Firebase Cloud Functions To Update  Firestore In RealTime Now, we'll create a cloud function in our file. This function will take an "id" as input. This id is provided by Google Maps Places API. index.js place_id It'll search and fetch the current user's document. We've already created an array while registering with the onCreate trigger. favTempleList The function then will look through the list and toggle the value. // Add temple to my fav list:
exports.addToFavList = functions.runWith({
    timeoutSeconds: 120,
    memory: "128MB"
}).https.onCall(async (data, context) => {
    const templeId = data.templeId;
    try {
        // Get user doc
        let userDocRef = await db.collection('users').doc(context.auth.uid).get();

        // extract favTempleLis from the doc
       // #1
        let favTempleList = userDocRef._fieldsProto.favTempleList;

        // if fav list is empty 
        // #2
     //============================//
        if (favTempleList.arrayValue.values.length === 0) {
            // Put the id in the list 
            const templeList = [templeId];
            functions.logger.log("Fav list is empty");
            
            // Update the favTemple list
            await db.collection('users').doc(context.auth.uid).set({ favTempleList: templeList }, { merge: true });
//============#2 ends here=====================//
        } else {
            functions.logger.log("Fav Temple List is not empty");
   
            // Make list of available ids
            // firebase providers arrays values as such fileName.arrayValue.values array 
            // consisting dictionary with stringValue as key and its value is the item stored
            // #3
            functions.logger.log(favTempleList.arrayValue.values[0]);
            let tempArrayValList = favTempleList.arrayValue.values.map(item => item.stringValue);

            // if not empty Check if the temple id already exists
           // #4
            let hasId = tempArrayValList.includes(templeId);

            // if so remove the id if no just add the list 
           // #5
//============================//
            if (hasId === true) {

                // Usr filter to remove value if exists
                let newTemplesList = tempArrayValList.filter(id => id !== templeId);

                await db.collection('users').doc(context.auth.uid).set({ favTempleList: newTemplesList }, { merge: true });
//==============#5 ends here===========//
            }
            // If the id doesnot already exists
           // #6
//============================//

            else {
                // first create a fresh copy
                let idList = [...tempArrayValList];

                // add the new id to the fresh list
                idList.push(templeId);

                // update the fresh list to the firesotre
                await db.collection('users').doc(context.auth.uid).set({ favTempleList: idList }, { merge: true });
//==============#6 ends here===========//

            }

        }

    } catch (e) { functions.logger.log(e); }

    // Return the Strig done. 
    //#7
    return "Done";
}); A couple of lines of code here are on other functions and triggers we've already done. So, let's only go over a few important ones: We are extracting the firebase field named "favTempleList" from the user documentation. That field is an array. We're checking if that array is empty. If so, we can just add the new place_id we got from the function call to the array and then update the doc. One thing to notice here is that I am using the merge option for an empty array. That's because this set() method doesn't just set/update a field in a doc, it sets/updates the whole document itself. So, if the **{merge: true} **option is not provided it'll overwrite every field there, in our case username, email, location, and so on. Now, we enter the section where the temple list is not empty. Then first we need to extract the list of values(id's) that are already present there. Check if the new ID, we got from the method call, is already present in the list we got from Firestore. If the id is already there then we need to remove it. We'll combine and methods. After filtering the current place_id, we'll update the Firestore user doc with the fresh list of ids. filter() includes() If the place_id is not there then we need to add it. We'll push the current place_id into the list. And then update the doc like before. Remember we should permanently terminate Firebase functions in the end. We don't need any data from this so we'll just terminate it by returning a string. Provider Now, we'll need to add a method in our Provider class that'll call the HTTPS callable function we just created. In our TempleProvider class let's add another method . addToFavList void addToFavList(String templeId) async {
    // Instantiate callable from index.js
    HttpsCallable addToFav = functions.httpsCallable('addToFavList');
    try {
      // Run the callable with the passing the current temples ID
      await addToFav.call(<String, String>{
        'templeId': templeId,
      });
    } catch (e) {
      rethrow;
    }
  } We're not updating or returning anything here. That's because we can get data from snapshots from a stream, as you'll see later. BTW, you could add this method to AuthStateProvider because it deals with user collection. Use Stream & StreamBuilder To Output Changes In RealTime We can simply use the for this. So, we'll connect with Firesotre with streams and update the screen with StreamBuilder.  So, where exactly are we using this StreamBuilder? Good question, you see getting real-time updates, means reloading(re-reading) the same collections on every change. It is obviously memory expensive. But it can cost expensive as well since Firebase charges for several reads. So, we don't want to load the list of temples, again and again, to toggle a single favorite icon. So, let's wrap only our favorite icon with stream builder instead. streams On temple_item_widget.dart make these changes. Create a function that'll call the addToFavList method from the provider class. // function to call addToFavList from provider class
  // It'll take id and providerclass as input
  void toggleFavList(String placeId, TempleProvider templeProvider) {
    templeProvider.addToFavList(placeId);
  } Inside the build method of class before the return statement. // Fetch the user doc as a stream
//#1
 Stream<DocumentSnapshot> qSnapShot = FirebaseFirestore.instance
        .collection('users')
        .doc(FirebaseAuth.instance.currentUser!.uid)
        .snapshots();

// Instantiate provider method to pass as argument for tooggle FavList
//#2
    TempleProvider templeProvider =
        Provider.of<TempleProvider>(context, listen: false); As mentioned before we'll get the Stream from Firestore, a document using the current user's ID. Instantiate provider method to pass as an argument for toggleFavList function. But make sure to turn off the listener. Replace FavIcon Section With StreamBuilder StreamBuilder(
                      // Use latest update provided by stream
                      // #1
                      stream: qSnapShot,
                      builder: (context, snapshot) {
                        if (snapshot.connectionState ==
                                ConnectionState.waiting ||
                            snapshot.connectionState == ConnectionState.none) {
                          return const CircularProgressIndicator();
                        } else {
                          // Get documentsnaphot which is given from the stream
                         // #2
                          final docData = snapshot.data as DocumentSnapshot;

                          // Fetch favTempleList array from user doc
                         // # 3
                          final favList = docData['favTempleList'] as List;

                          // Check if the curent widget id is among the favTempLlist
                         // #4
                          final isFav = favList.contains(widget.itemId);

                          return Expanded(
                            child: IconButton(
                                // Call toggleFavlist method on tap
                               // #5
                                onPressed: () => toggleFavList(
                                    widget.itemId, templeProvider),
                                icon: Icon(
                                  Icons.favorite,
                                  // Show color by value of isFav
                                 // #6
                                  color: isFav ? Colors.red : Colors.grey,
                                )),
                          );
                        }
                      }) Here, in the StreamBuilder Class we: Used the stream we got from Firestore 'users' collection as a stream. That way the latest change is
reflected asap. When the ConnectionState is done, first we get the latest data from the snapshot, which will be the current user's doc. Get the latest updated favTempleList array as a List from the document. Check if the current ID exists in the favItemList, which is the field passed down from the temples screen. itemId On pressing the heart icon button call the toggleFavList method of the class. Change the color of the heart icon based on the presence or absence of itemId on favTempleList. And with that latest real-time changes will be reflected in the app. Final Code The file looks like this after the changes. temple_item_widget.dart import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:firebase_auth/firebase_auth.dart';
import 'package:flutter/material.dart';
import 'package:provider/provider.dart';
import 'package:temple/screens/temples/providers/temple_provider.dart';

class TempleItemWidget extends StatefulWidget {
  // Fields that'll shape the Widget
  final String title;
  final String imageUrl;
  final String address;
  final double width;
  final String itemId;

  const TempleItemWidget(
      {required this.title,
      required this.imageUrl,
      required this.address,
      required this.width,
      required this.itemId,

      // required this.establishedDate,
      Key? key})
      : super(key: key);

  @override
  State<TempleItemWidget> createState() => _TempleItemWidgetState();
}

class _TempleItemWidgetState extends State<TempleItemWidget> {
  // function to call addToFavList from provider class
  // It'll take id and providerclass as input
  void toggleFavList(String placeId, TempleProvider templeProvider) {
    templeProvider.addToFavList(placeId);
  }

  @override
  Widget build(BuildContext context) {
    // Fetch the user doc as stream
    Stream<DocumentSnapshot> qSnapShot = FirebaseFirestore.instance
        .collection('users')
        .doc(FirebaseAuth.instance.currentUser!.uid)
        .snapshots();

// Instantiate provider method to pass as argument for tooggle FavList
    TempleProvider templeProvider =
        Provider.of<TempleProvider>(context, listen: false);

    return SizedBox(
      // Card will have height of 260
      height: 260,
      width: widget.width,
      child: Card(
        key: ValueKey<String>(widget.itemId),
        elevation: 4,
        shape: RoundedRectangleBorder(
          borderRadius: BorderRadius.circular(10),
        ),
        margin: const EdgeInsets.all(10),
        child: Column(
          // Column will have two children stack and a row
          children: [
            // Stack will have two children image and title text
            Stack(
              children: [
                ClipRRect(
                  borderRadius: const BorderRadius.only(
                    topLeft: Radius.circular(10),
                    topRight: Radius.circular(10),
                  ),
                  child: Image.network(
                    widget.imageUrl,
                    fit: BoxFit.cover,
                    width: widget.width,
                    height: 190,
                  ),
                ),
                Positioned(
                  bottom: 1,
                  child: Container(
                    color: Colors.black54,
                    width: widget.width,
                    height: 30,
                    child: Text(
                      widget.title,
                      style: Theme.of(context)
                          .textTheme
                          .headline2!
                          .copyWith(color: Colors.white),
                      // softWrap: true,
                      overflow: TextOverflow.fade,
                      textAlign: TextAlign.center,
                    ),
                  ),
                ),
              ],
            ),
            Row(
                // Rows will have two icons as children

                crossAxisAlignment: CrossAxisAlignment.center,
                mainAxisAlignment: MainAxisAlignment.spaceEvenly,
                children: [
                  Expanded(
                    child: IconButton(
                      onPressed: () {
                        print("Donate Button Pressed");
                      },
                      icon: const Icon(
                        Icons.attach_money,
                        color: Colors.amber,
                      ),
                    ),
                  ),
                  StreamBuilder(
                      // User the ealier stream
                      stream: qSnapShot,
                      builder: (context, snapshot) {
                        if (snapshot.connectionState ==
                                ConnectionState.waiting ||
                            snapshot.connectionState == ConnectionState.none) {
                          return const CircularProgressIndicator();
                        } else {
                          // Get documentsnaphot which is given from the stream
                          final docData = snapshot.data as DocumentSnapshot;
                          // Fetch favTempleList array from user doc
                          final favList = docData['favTempleList'] as List;
                          // Check if the curent widget id is among the favTempLlist
                          final isFav = favList.contains(widget.itemId);
                          return Expanded(
                            child: IconButton(
                                // Call toggleFavlist method on tap
                                onPressed: () => toggleFavList(
                                    widget.itemId, templeProvider),
                                icon: Icon(
                                  Icons.favorite,
                                  // Show color by value of isFav
                                  color: isFav ? Colors.red : Colors.grey,
                                )),
                          );
                        }
                      })
                ]),
          ],
        ),
      ),
    );
  }
} Summary In this exciting blog we: Created a Firebase HTTP Callable function to update a document in Firestore. We also wrote a simple instruction in the provider class to handle the callable. Lastly using stream and stream builder we displayed real-time changes on our screen. Show Support Alright, this is it for this time. The next part will be the last one for this series. We won't be doing anything new there. I'll give you some tasks to do on your own to continue this app and practice what you've learned so far. I'll also enlist some courses, blogs, and books that have helped me a lot to learn flutter. Please like, comment, and share the article with your friends. Thank you for your time and for those who are subscribing to the blog's newsletter, we appreciate it. Keep on supporting us.  This is Nibesh from Khadka's Coding Lounge, a freelancing agency that makes websites and mobile applications. Also Published here

How to Stream Real-time Changes With Firebase, Firestore and Flutter

Android Unidirectional Data Flow with LiveData Improving Coinverse’s Performance and Structure (UDF) pattern has improved the usability and performance of since the first beta launched in February. Coinverse is the first app creating audiocasts covering technology and news in cryptocurrency. Upgrades using UDF include more efficient newsfeed creation, removal of adjacent native ads, and faster audiocast loading. The Unidirectional Data Flow Coinverse The UDF pattern organizes the app into three main areas, view , and ensuring the app is modularized and reliable. I learned of the UDF pattern from episode 148 of the , with at and . On first listen it was interesting, but a large overhaul. UDF became compelling as I worked on fixing bugs and realized how complex various flows had become. state, events effects Fragmented podcast Evolving Android architectures (Part 1) Kaushik Gopal Instacart Donn Felker The examples of UDF I’ve seen thus far have been with . Rx a powerful and customizable tool for creating streams of data that can be observed in real-time. However, provides the same benefit of observing state changes and on top of that is simple, directly integrates with Android’s , and handles Android’s lifecycle events by default. If unfamiliar, check out Google’s ’s . To try out UDF I refactored the newsfeed flows in Coinverse as we’ll walkthrough below. Rx LiveData architecture components Jose Alcérreca talk on LiveData <a href="https://medium.com/media/8b9dd6f492bd3f25f79f7bf5cbe0388e/href">https://medium.com/media/8b9dd6f492bd3f25f79f7bf5cbe0388e/href</a> UDF Background UDF pattern, a.k.a. or was originally popularized in web development with Facebook’s and state management, and UI libraries. Early Android can be found from and at in 2015. ’s talks on Rx educated developers on which are fundamental to UDF. Unidirectional Data State Flow React Readux Flux experimentation Brian Egan Guillaume Lung SoundCloud Jake Wharton reactive programming Growing Number of Android Apps Adopting To name a few… and @ Kaushik Gopal Laimonas Turauskas Instacart @ Robinhood Dan Hill @ / Lyft Donald Chen Instagram Engineering @ Microsoft Cesar Valiente App companies adopting UDF Model View View Model — MVVM Gem Lake, Yosemite Emigrant Wilderness Trail For the first iteration of Coinverse I used the (MVVM) approach. MVVM separates the UI from the business logic, improving readability and organization. However, as an app grows with MVVM it becomes a lake of data. Information flows in, out, and around at many points via and with , and . This adds complexity for keeping track of logic, debugging, and testing, which requires mocking many components. Model View View Model Activities Fragments Data Binding, ViewModels Repositories UDF Advantages pc — , Waterfall at Yosemite National Park Ned Scher UDF is a waterfall, information flows in one direction through a single source providing many benefits. One point of entry for streams — The UI and business logic interact through single points of entry. Control UI involving async events — Know exactly when and where things begin and finish Debug issues — Easy to follow sequence of events and identify errors Streamlined tests — The majority of logic is contained in the ViewModel requiring less mocking. LiveData LiveData provides a straightforward approach to implementing UDF. Lifecycle aware Can emit multiple or single events Concise code Quick to implement <a href="https://medium.com/media/aece5d95a459fab51fe4afcff559f91b/href">https://medium.com/media/aece5d95a459fab51fe4afcff559f91b/href</a> View State, Events, and Effects ViewState Coinverse’s main newsfeed View is responsible for holding the final view’s persisted data. This entails all of the content shown to a user on a screen, including information about the content such as enabled statuses. state Looking at Coinverse’s main newsfeed above, examples of view include the contents of the toolbar, what timeframe and the feedtype of feed to display, as well as the contentList to populate the feed with. state Events ContentSelected(…) View consist of both user interface and system initiated actions. UI actions include button presses and text input, whereas system actions might be Android lifecycle events and screen rotation. events In the case of content selected above a view is created, ContentSelected. The will share information with the business layer to initiate the retrieval of the audiocast selected. The Coinbase Blog’s event event Effects ContentSwiped(…) View are one time UI occurrences that don’t persist. include navigation, dialogs, and toasts. are created by the business layer to initiate changes in the UI. effects Effects Effects When the item above is swiped right, the business layer adds a label to the content. The business layer sends an , ContentSwiped**,** informing the UI of the change in the content’s label. The UI can then remove the content from the main newsfeed. CCN saved effect App Structure Let’s understand how the one-way flow of data is structured. The handles all UI and system level actions stored in a single stream. The stream is sent to the that receives the actions and handles them accordingly in the business logic. View ViewModel The is the source of truth for the view and creates any necessary . The also handles requests to the data layer, managing the results , success ( ), and states returned from the with an Lce object (more on Lce's below). ViewModel state effects ViewModel Repository loading content error Repository Both the and are observed by the updating any changes from the in real-time. state effects View, ViewModel Implementation mainfeed loading We’ll use Coinverse’s main newsfeed loading as our example for how to implement UDF. Step 1 of 6 — Define Models <a href="https://medium.com/media/e3e457ec723be5f770f4c050214571d0/href">https://medium.com/media/e3e457ec723be5f770f4c050214571d0/href</a> View Stored as a LiveData object in the storing the contentList of LiveData type state — ViewModel, View and — Use Kotlin’s to pass one time events event effect Sealed class The view uses LiveData because it’s important the data is immutable vs. MutableLiveData. Otherwise, the flow of data would not be unidirectional, and the state could be changed in many places. state View and are not persisted in the . A Sealed class, like an Enum, but on a class level, is used to pass information. Sealed classes define a parent and child class with or without data. TheScreenLoad is a data class with data about what the should load. Whereas the UpdateAds is a class without data telling the view to update the ads in the newsfeed. events effects ViewModel event ViewModel effect Step 2 of 6 — Pass events to ViewModel <a href="https://medium.com/media/21b7345af796983c640793c3fbfdf7ee/href">https://medium.com/media/21b7345af796983c640793c3fbfdf7ee/href</a> In this example, when the system action of onCreate occurs, a ScreenLoad event is added to the stream of view events and sent from the to the to start creating the main feed. Fragment ViewModel All of the events created in the / are added to a object _viewEvent, a MutableLiveData object which updates the immutable LiveData object. I’m using the pattern of passing all of the events in onResume based on ’s . View Fragment LiveData Kaushik sample The LiveData stores data wrapped in an Event. As explained by in his , events ensure a single unique object is added to a stream. This avoids the accidental creation of multiple objects for a single action. Jose LiveData post about events Step 3 of 6 — Process events mainfeed loaded <a href="https://medium.com/media/1e82719128462cbbc400fb2ceab73db4/href">https://medium.com/media/1e82719128462cbbc400fb2ceab73db4/href</a> The receives incoming events, handling each event in a when statement based on the type of ViewEvent class. For ScreenLoad, the entireViewState is updated with the required data. To populate the newsfeed a request to the with getMainFeed is made. ViewModel Sealed Repository Update State Value In cases where an attribute of the ViewState needs to be updated rather than the entire ViewState, Kotlin’s shallow function is useful. copy <a href="https://medium.com/media/ce1bf00297c228e57a7216047f915529/href">https://medium.com/media/ce1bf00297c228e57a7216047f915529/href</a> Step 4 of 6 — Manage Network Requests with LCE Pattern <a href="https://medium.com/media/abb3971ab92689aa13784def4501b3e3/href">https://medium.com/media/abb3971ab92689aa13784def4501b3e3/href</a> To manage network requests, introduces the Lce class object with three states, , , and . The state represents a successful request. Kaushik Sealed loading content error content <a href="https://medium.com/media/115cf44f615dca588145ff82c08df8f1/href">https://medium.com/media/115cf44f615dca588145ff82c08df8f1/href</a> A class is also useful for returning different types of results. Sealed <a href="https://medium.com/media/0282a893889f04b825cc9f73d6a231fb/href">https://medium.com/media/0282a893889f04b825cc9f73d6a231fb/href</a> getMainFeed’s network request shares send the Lce states to the via the LiveData stream. The PagedListResult class can be passed into the Lce for both the and states. The will then manage each state appropriately. ViewModel content error ViewModel Step 5 of 6 — Handle LCE States mainfeed error The gif shows something has gone awry. We’ll see how the error is handled in the . ViewModel <a href="https://medium.com/media/2e31d1bd3a6304c6a19b4728f9102597/href">https://medium.com/media/2e31d1bd3a6304c6a19b4728f9102597/href</a> UDF has streamlined both methods of requesting new content from the network and retrieving the updated content from the database. Prior to using UDF, Coinverse called two repository methods separately to populate the main newsfeed. Room When the feed is loading the existing Room database content is returned so that the user is not staring at an empty screen. For the successful Content case, the updated content from Room is returned. For errors requesting new content, the existing Room content is also displayed similar to theLoading case. In the error above, a SnackBar view is passed to the to display the error message. effect Fragment The observes each Lce state with a LiveData SwitchMap. The SwitchMap passes in one LiveData object and returns a new and different LiveData object that is saved to the view . ViewModel state Like all LiveData, a SwitchMap must be observed in the view in order for the value to be emitted within the map inside the . ViewModel Step 6 of 6 — Observe State Change! <a href="https://medium.com/media/503f19392a8e77dba776d7ab367549a1/href">https://medium.com/media/503f19392a8e77dba776d7ab367549a1/href</a> Now the view may be observed when an update occurs. The view are observed in the same way. state effects Bonus — Removing Adjacent Ads auto adjacent ads detection In addition to a streamlined newsfeed above, UDF has improved how Twitter’s native ads are shown in the newsfeed. MoPub’s MoPubRecyclerAdapter does not have a built-in approach to avoid adjacent ads from showing. Content can be swiped to be saved or dismissed, eventually causing two ads to appear next to each other. Prior to UDF, this was handled with a manual swipe-to-refresh by the user. MoPub With UDF there is a contentLabeled view . When the status of the view changes, meaning an item is labeled to be removed from the main feed, a check for adjacent ads is made. If removing the content creates adjacent ads, the ads are automatically refreshed. state state Trade-Offs Using LiveData for the Unidirectional Data Flow has been great, but it’s not perfect. LiveData is only applicable for logic impacting the UI. For non-UI logic LiveData will not be observed since it requires lifecycle to be passed in. For these instances, or Rx may be used. If no UI is involved then an even better solution might be to offload the logic completely to the backend with . Kotlin coroutines Firebase Cloud Functions There’s not as much customization with LiveData for things like threading. With this year’s latest Google I/O updates coroutines appear to easily integrate with LiveData offering more customization. Coinverse Next Steps Expanding to the rest of Coinverse’s app Unidirectional Data Flow — — Now that the majority of the newsfeed logic is modularized in the , JUnit testing will be easier with less mocking of components. JUnit testing ViewModel Exploring integration with LiveData Kotlin coroutines — Resources Slides — @ Unidirectional Data Flow por Adam Hurwitz Medellín Android MeetUp Notes — Unidirectional Data Flow guide I’d love your feedback on the beta! Coinverse to be updated on a Unidirectional Data Flow sample app and more. Follow me A to and of the for organizing the talk! If you are in Medellín I recommend stopping by their MeetUp. big thanks Cristián Gomez Carlos Daniel Medellín Android MeetUp Medellín Android talk — Unidirectional Data Flow por Adam Hurwitz

Android Unidirectional Flow with LiveData

Back in 2014 I started my career as android application developer, I worked on many projects including core android apps which required deep knowledge of android SDKs and also NDK. Other than that I also worked on IOT projects which included connecting with external and on-device sensors. I enjoy being challenged and engaging with projects that require me to work outside my comfort and knowledge set, therefore I started looking into iOS development later in 2017. Knowing the mobile eco-system, it wasn’t much difficult for me to getting along and thanks to the sister languages, kotlin and swift, there was almost zero effort to work on swift. TL;DR From Android to iOS development — highlighting the better things Root view controller I was writing a network wrapper for iOS to manage all network calls.Whenever network request is made, loader dialog is shown and is removed when call is ended. Imagine doing it in android :@ What would you do? pass a context in every function, function by function or putting it in a constants file? using application context (which introduces a new set of problems). (Not the ideal way, but it was a small app) currentVC = rootVC.presentedViewController ?? rootVC!currentVC.present(screenLoader, animated: ) let false Creating custom views Ever created custom view for android? Some heavy chart? Remember problems with onDraw? It being fired more than once? or do you remember onLayoutSubviews where you request for the view size?Well, iOS manages it beautifully. It’s not like we don’t have onDraw in iOS but it is different, frame and bounds are really powerful. draw( rect: CGRect) { .draw(rect) override func _ super **self**.layer.borderColor = UIColor.blue.cgColor  
**self**.layer.cornerRadius = **self**.frame.height/2  
**self**.layer.borderWidth = 2.0  
**self**.clipsToBounds = **true  
self**.setTitleColor(.white, for: .highlighted)  
(buttonColor = buttonColor) } Or you can also use auto layout in custom view. . See example here Storyboard Android developers have been away from this blessing, anyhow they are catching up now.There is to learn such as XML. You don’t have to see the code for sometime which is also a good feeling. Drag and drop is lot easy, you can say, common sense is required for building simple UIs.No view ids — phew. are something from heaven, well kotlinx synthetic has also made it a lot easier but aren’t mature enough.Another beautiful thing about storyboard are the , the navigation between the view controllers, a proper, better backstack and understanding of the app flow.Ever implemented bottom bar/tab bar? Had to work with the fragments? Maintaining multiple lifecycles? Try doing it on iOS :) no markup language IBOutlets and IBActions seagues Dependency Injection Dagger and Koin are the most popular dependency injection libraries in android, they require a tricky setup and lots of code, specially autogenerated, and they come with their own set of bugs and errors.In iOS, we do not require any library but technique which is less prone to errors and easier to implement. Call Kit We worked on a chat application which included audio/video call. There were tons of things we had to take care of in android. Setting the wake-lock, proximity sensor to disable the screen, keep screen on, running the timer etc.Whereas iOS comes with call kit which already handle all these cases :) Anyhow, call kit helps but it also limit developers. Target Devices Apple has the limited number of devices running on iOS: iPhone, iPod and iPad. Moreover, the shows, that over 50% of users updated their operating systems to the latest version (iOS 11) during the first 3 weeks after the release. It makes lives of iOS developers easier. A development process flows faster because you have to build your app for a narrow range of devices and operating systems. most recent statistics But if we talk about Android, it’s just a mess. There are dozens of smartphones and tablets on Android with different screen sizes and aspect ratios. It means your app should be suitable for all of them. Or at least for the biggest part.The same thing is about operating systems. Here you can’t find any, which is used by of Android device owners. And it means that you again have to consider this difference while building your app. more than 50% XCode IDE When it comes to the IDE, android studio is lot better in many things, such as giving suggestions, navigation by clicking on the class, improving code snippet etc. but when it comes to speed, XCode is way better, android studio is memory hungry. It takes lot of time to import a project or even running the project can be very frustrating at times specially in debug mode. Conclusion It is not like that iOS is better than Android for development aspect, both have their own pros and cons. This post focuses on few pros I have experienced in last year. If there are any other things I missed, please comment and if you liked it please clap :)

Stories, News & Mentions about SCREENCLOUD

Screencloud’s Stories on HackerNoon