SyncMama

syncmama

Last year, my wife and I gained the first-time experience of building a brand-new home. The process was fun and exciting, but we also experienced the unexpected internet service interruptions that often accompany new home subdivisions. While these outages impacted my family’s ability to stream services, such as Amazon Prime, Hulu, and Netflix, I continued working on my current project, due to the intentional design of being able to work in an isolated (or offline) state. This has always been helpful during airline travel when I work from Nevada and Florida during the year. This made me wonder why more mobile apps are not designed to continue working during internet service interruptions. In this publication, I will demonstrate just how easy it is to make your mobile app usable in offline mode. Since I recently spent time with the , I wanted to continue exploring that mobile app option. Salesforce Mobile SDK Working Offline with Salesforce Mobile SDK Before we get into writing code, let’s touch briefly on how offline functionality works with the Salesforce Mobile SDK. The left side of the illustration presents the traditional manner in which the Salesforce application is utilized. The right side provides a high-level overview of the Salesforce Mobile SDK. Native applications that run on Android or iOS devices can be written in Android Studio, Xcode, or React Native. Those applications include the user interface, some level of business logic, and model objects representing elements that ultimately live in Salesforce. The Salesforce Mobile SDK includes a SmartStore aspect, which makes data available when the mobile application cannot access the Salesforce service. The model layer can be easily designed to leverage the SmartStore when offline mode is required (or preferred), but ready to synchronize all changes with Salesforce when online status is available. If you want to read more about this design, check out “ .” Using SmartStore to Securely Store Offline Data Adding Offline-ability to Finny’s Foods Earlier this year, I explored the Salesforce Mobile SDK and created a fictional app called Finny’s Foods. I created the app three times using Android, iOS, and React Native. I thought I would start from the that used the iOS/xCode (Swift) version of the Salesforce Mobile SDK, then build upon it to provide offline functionality. publication The GitLab repository for the original article is listed below: https://gitlab.com/johnjvester/finnys-foods-ios The first step is to establish the object in the file that is used by the SmartStore functionality. Meal__c userstore.json {
  "soups": [
    {
      "soupName": "Meal__c",
      "indexes": [
        { "path": "Id", "type": "string"},
        { "path": "Name", "type": "string"},
        { "path": "Rating__c", "type": "integer"},
        { "path": "__local__", "type": "string"}
      ]
    }
  ]
} Next, update the file to make the current list of meals available offline: usersyncs.json {
  "syncs": [
    {
      "syncName": "syncDownMeals",
      "syncType": "syncDown",
      "soupName": "Meal__c",
      "target": {"type": "soql", "query":"SELECT Id, Name, Rating__c FROM Meal__c ORDER BY Name ASC"},
      "options": {"fieldlist":["Id", "Name", "Rating__c", "LastModifiedDate"], "mergeMode":"LEAVE_IF_CHANGED"}
    }
  ]
} You can read all about the SmartStore sync configuration in “ .” Registering Soups with Configuration Files With the SmartStore configuration in place, I refactored the class as shown below: MealsListModel.swift class MealsListModel: ObservableObject {
    
    @Published var meals: [Meal] = []
    
    var store: SmartStore?
    var syncManager: SyncManager?
    private var syncTaskCancellable: AnyCancellable?
    private var storeTaskCancellable: AnyCancellable?
    
    init() {
         store = SmartStore.shared(withName: SmartStore.defaultStoreName)
         syncManager = SyncManager.sharedInstance(store: store!)
    }
     
    func fetchMeals(){
         syncTaskCancellable = syncManager?.publisher(for: "syncDownMeals")
             .receive(on: RunLoop.main)
             .sink(receiveCompletion: { _ in }, receiveValue: { _ in
                 self.loadFromSmartStore()
         })
         self.loadFromSmartStore()
     }
     
     private func loadFromSmartStore() {
          storeTaskCancellable = self.store?.publisher(for: "select {Meal__c:Id}, {Meal__c:Name}, {Meal__c:Rating__c} from {Meal__c}")
             .receive(on: RunLoop.main)
             .tryMap {
                 $0.map { (row) -> Meal in
                     let r = row as! [String?]
                     return Meal(id: r[0] ?? "", Name: r[1] ?? "", Rating__c: (r[2]! as NSString).doubleValue)
                 }
             }
             .catch { error -> Just<[Meal]> in
                 print(error)
                 return Just([Meal]())
             }
             .assign(to: \MealsListModel.meals, on:self)
     }
} I updated the function to interact with the SmartStore by default, calling Salesforce when needed but allowing data stored in the application to be used if the device is in offline mode. fetchMeals() Believe it or not, that’s all that is required. Finny’s Foods in Offline Action After launching Finny’s Foods from XCode and an iPhone 8 emulator, we see the following screen displayed as it did in the original publication. Now, if I disconnect my device from the internet and reload the application, the following logs appear in XCode: 2022-03-14 16:14:15.544412-0400 FinnysFoodsIOS[88679:6546397] [MobileSync] CLASS: SFSyncDownTask runSync failed:{ ... } cause:Server call for sync down failed errorError Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." However, the application still loads and provides the data from the SmartStore. In fact, without looking at the logs in XCode, I would have had no idea that I was working with a local version of the data. For offline applications which allow data to be added or updated, the SmartStore has the ability to merge offline and online data with a Sync Manager. See the__ __ documentation for additional information. Syncing Data Conclusion Although internet connectivity continues to improve, a reliable connection is not 100% guaranteed. Forward-thinking feature developers should consider taking the appropriate steps to allow their apps to continue working when an internet connection is not available. Ask yourself: How can my app be better when working in a disconnected state? Since 2021, I have been trying to live by the following mission statement, which I feel can apply to any IT professional: ** ** “Focus your time on delivering features/functionality which extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester In this article, I provided an example of how easy it is to implement offline functionality using the Salesforce Mobile SDK. Salesforce engineering designed the integration point at the model layer, and that’s the best place to determine if live data can be retrieved or if SmartStore data should be returned. Clearly, Salesforce adheres to my personal mission statement by offering a design that is easy to employ without a great deal of boilerplate code. If you are interested in the source code for this article, you can find it on GitLab here: https://gitlab.com/johnjvester/finnys-foods-ios Have a really great day!

Taking Your App Offline with the Salesforce Mobile SDK

This is our final post in our three-part series demonstrating how to use the Salesforce Mobile SDK to build an Android app that works with the Salesforce platform. , we showed you how to connect to your org. showed you how to edit and add data to your org from your app. This post will show you how to synchronize data from your Salesforce org to your mobile device and handle scenarios such as network loss. Let’s get right into it! In our first post Our second post Working with Mobile Sync One of the hardest aspects of mobile development is dealing with data synchronization. How do you handle the situation when you need to add a new broker, but you’re offline? Or what if two agents are updating the same broker—how can you handle the merging of those two changes? With the Salesforce Mobile SDK, these real-world issues are handled for you by a system called . Mobile Sync has you map your phone’s local data to the data in Salesforce; it also requires you to define operations for fetching and pushing data—what it calls and . Mobile Sync syncDown syncUp Define the shape of data to be synced To get started with Mobile Sync, create a file in called : res/raw brokerstore.json {
 "soups": [
   {
     "soupName": "brokers",
     "indexes": [
       { "path": "Id", "type": "string"},
       { "path": "Name", "type": "string"},
       { "path": "Title__c", "type": "string"},
       { "path": "Phone__c", "type": "string"},
       { "path": "Mobile_Phone__c", "type": "string"},
       { "path": "Email__c", "type": "string"},
       { "path": "Picture__c", "type": "string"},
       { "path": "__local__", "type": "string"},
       { "path": "__locally_created__", "type": "string"},
       { "path": "__locally_updated__", "type": "string"},
       { "path": "__locally_deleted__", "type": "string"},
       { "path": "__sync_id__", "type": "integer"}
     ]
   }
 ]
} This file defines the shape of the data on your phone, as well as some additional metadata that’s necessary for the sync. Next, create a file called : brokersync.json {
 "syncs": [
   {
     "syncName": "syncDownBrokers",
     "syncType": "syncDown",
     "soupName": "brokers",
     "target": {"type":"soql", "query":"SELECT Name, Title__c, Phone__c, Mobile_Phone__c, Email__c, Picture__c FROM Broker__c LIMIT 10000"},
     "options": {"mergeMode":"OVERWRITE"}
   },
   {
     "syncName": "syncUpBrokers",
     "syncType": "syncUp",
     "soupName": "brokers",
     "target": {"createFieldlist":["Name", "Title__c", "Phone__c", "Mobile_Phone__c", "Email__c", "Picture__c"]},
     "options": {"fieldlist":["Id", "Name", "Title__c", "Phone__c", "Mobile_Phone__c", "Email__c", "Picture__c"], "mergeMode":"LEAVE_IF_CHANGED"}
   }
 ]
} These are the operations that Mobile Sync will use when syncing data down and up. The code to complete the Mobile Sync process depends on several factors, such as when you want to perform a synchronization, as well as hooking into the Android event cycle when a device loses (and regains) connectivity. The following code samples will show you a complete example of what needs to happen to get synchronization working, but they should be considered high-level concepts, and not necessarily production-ready enterprise-grade code. Set up periodic sync With that said, let’s take a look at how to implement synchronization. First, add this line to the end of our method in : onResume(client: RestClient) MainActivity.kt setupPeriodicSync(); Next, we’ll add a new variable and a new function to the class: MainActivity private val SYNC_CONTENT_AUTHORITY =
   "com.salesforce.samples.mobilesyncexplorer.sync.brokersyncadapter"

private fun setupPeriodicSync() {
   val account = MobileSyncSDKManager.getInstance().userAccountManager.currentAccount

   ContentResolver.setSyncAutomatically(account, SYNC_CONTENT_AUTHORITY, true)
   ContentResolver.addPeriodicSync(
       account, SYNC_CONTENT_AUTHORITY,
       Bundle.EMPTY, 10
   )
} Since we’re using in our function, let’s make sure to import it by adding this line alongside the other import statements near the top of : ContentResolver MainActivity.kt import.android.content.ContentResolver We have defined two methods that trigger synchronization. will run a sync every seconds. This is much too frequent for a production environment, but we’ll set it this way for demonstration purposes. setupPeriodicSync 10 Mapping sync operations to our data and UI We will show the next few code samples all at once, and discuss what they’re doing afterward. In , create a new file called and paste these lines into it: app/java/com.example.sfdc BrokerSyncAdapter.kt package com.example.sfdc

import android.accounts.Account
import android.content.AbstractThreadedSyncAdapter
import android.content.ContentProviderClient
import android.content.Context
import android.content.SyncResult
import android.os.Bundle
import com.salesforce.androidsdk.accounts.UserAccount
import com.salesforce.androidsdk.accounts.UserAccountManager
import com.salesforce.androidsdk.app.SalesforceSDKManager
import com.example.sfdc.BrokerListLoader

class BrokerSyncAdapter
   (
   context: Context?, autoInitialize: Boolean,
   allowParallelSyncs: Boolean
) :
   AbstractThreadedSyncAdapter(context, autoInitialize, allowParallelSyncs) {
   override fun onPerformSync(
       account: Account, extras: Bundle, authority: String,
       provider: ContentProviderClient, syncResult: SyncResult
   ) {
       val syncDownOnly = extras.getBoolean(SYNC_DOWN_ONLY, false)
       val sdkManager = SalesforceSDKManager.getInstance()
       val accManager = sdkManager.userAccountManager
       if (sdkManager.isLoggingOut || accManager.authenticatedUsers == null) {
           return
       }
       if (account != null) {
           val user = sdkManager.userAccountManager.buildUserAccount(account)
           val contactLoader = BrokerListLoader(context, user)
           if (syncDownOnly) {
               contactLoader.syncDown()
           } else {
               contactLoader.syncUp() // does a sync up followed by a sync down
           }
       }
   }

   companion object {
       // Key for extras bundle
       const val SYNC_DOWN_ONLY = "syncDownOnly"
   }
} Now, in that same folder, create with these lines: BrokerListLoader.kt package com.example.sfdc

import android.content.AsyncTaskLoader
import android.content.Context
import android.content.Intent
import android.util.Log
import com.salesforce.androidsdk.accounts.UserAccount
import com.salesforce.androidsdk.app.SalesforceSDKManager
import com.salesforce.androidsdk.mobilesync.app.MobileSyncSDKManager
import com.salesforce.androidsdk.mobilesync.manager.SyncManager
import com.salesforce.androidsdk.mobilesync.manager.SyncManager.MobileSyncException
import com.salesforce.androidsdk.mobilesync.manager.SyncManager.SyncUpdateCallback
import com.salesforce.androidsdk.mobilesync.util.SyncState
import com.salesforce.androidsdk.smartstore.store.QuerySpec
import com.salesforce.androidsdk.smartstore.store.SmartSqlHelper.SmartSqlException
import com.salesforce.androidsdk.smartstore.store.SmartStore
import org.json.JSONArray
import org.json.JSONException
import java.util.ArrayList

class BrokerListLoader(context: Context?, account: UserAccount?) :
   AsyncTaskLoader<List<String>?>(context) {
   private val smartStore: SmartStore
   private val syncMgr: SyncManager
   override fun loadInBackground(): List<String>? {
       if (!smartStore.hasSoup(BROKER_SOUP)) {
           return null
       }
       val querySpec = QuerySpec.buildAllQuerySpec(
           BROKER_SOUP,
           "Name", QuerySpec.Order.ascending, LIMIT
       )
       val results: JSONArray
       val brokers: MutableList<String> = ArrayList<String>()
       try {
           results = smartStore.query(querySpec, 0)
           for (i in 0 until results.length()) {
               brokers.add(results.getJSONObject(i).getString("Name"))
           }
       } catch (e: JSONException) {
           Log.e(TAG, "JSONException occurred while parsing", e)
       } catch (e: SmartSqlException) {
           Log.e(TAG, "SmartSqlException occurred while fetching data", e)
       }
       return brokers
   }

   @Synchronized
   fun syncUp() {
       try {
           syncMgr.reSync(
               SYNC_UP_NAME
           ) { sync ->
               if (SyncState.Status.DONE == sync.status) {
                   syncDown()
               }
           }
       } catch (e: JSONException) {
           Log.e(TAG, "JSONException occurred while parsing", e)
       } catch (e: MobileSyncException) {
           Log.e(TAG, "MobileSyncException occurred while attempting to sync up", e)
       }
   }

   /**
    * Pulls the latest records from the server.
    */
   @Synchronized
   fun syncDown() {
       try {
           syncMgr.reSync(
               SYNC_DOWN_NAME
           ) { sync ->
               if (SyncState.Status.DONE == sync.status) {
                   fireLoadCompleteIntent()
               }
           }
       } catch (e: JSONException) {
           Log.e(TAG, "JSONException occurred while parsing", e)
       } catch (e: MobileSyncException) {
           Log.e(TAG, "MobileSyncException occurred while attempting to sync down", e)
       }
   }

   private fun fireLoadCompleteIntent() {
       val intent = Intent(LOAD_COMPLETE_INTENT_ACTION)
       SalesforceSDKManager.getInstance().appContext.sendBroadcast(intent)
   }

   companion object {
       const val BROKER_SOUP = "brokers"
       const val LOAD_COMPLETE_INTENT_ACTION =
           "com.salesforce.samples.mobilesyncexplorer.loaders.LIST_LOAD_COMPLETE"
       private const val TAG = "BrokerListLoader"
       private const val SYNC_DOWN_NAME = "syncDownBrokers"
       private const val SYNC_UP_NAME = "syncUpBrokers"
       private const val LIMIT = 10000
   }

   init {
       val sdkManager = MobileSyncSDKManager.getInstance()
       smartStore = sdkManager.getSmartStore(account)
       syncMgr = SyncManager.getInstance(account)
       // Setup schema if needed
       sdkManager.setupUserStoreFromDefaultConfig()
       // Setup syncs if needed
       sdkManager.setupUserSyncsFromDefaultConfig()
   }
} What did we just do? Each file has a specific role, and while the objects and fields will certainly be different for your app, the functions and philosophies of these classes are the same: is responsible for mapping the sync operations you defined in with the Kotlin code that will actually perform the work. Notice that there are and methods that use the Mobile SDK’s to load the JSON files and communicate back and forth with Salesforce. BrokerListLoader brokersync.json syncUp syncDown SyncManager can perhaps best be thought of as the code that’s responsible for scheduling the synchronization. That is, it’s the entry point for , and can be called by UI elements (such as during a refresh button click) or Android system events (such as connectivity loss). BrokerSyncAdapter BrokerListLoader Lastly, we need to add one line to our file (in ). Our new sync functionality will need special Android permissions, which we ask the user to allow upon app installation at runtime. Add the following line with to the end of your manifest: AndroidManifest.xml app/manifests WRITE_SYNC_SETTINGS <uses-permission android:name="com.example.sfdc.C2D_MESSAGE" />
  <uses-permission android:name="android.permission.WRITE_SYNC_SETTINGS" />
</manifest> Testing sync Our last step is to test that mobile sync works. With the emulator running, you should be logged in and see a list of brokers. This list should mirror the broker list that you see in your web browser on your local machine. In your web browser, edit one of the broker names, and save that change. Then, in your emulator, you can power off the phone or switch to another application and then switch back to your . You should see your list of broker names updated with the change you made in your browser: sfdc-mobile-app And that’s all! Again, this is just a foundational building block for you to learn from. In just about 150 lines of code, we’ve devised a solution for a rather complicated series of moving parts: Mapping Salesforce custom objects to JSON Setting up a timer to periodically sync data back and forth between a Salesforce org and a mobile device Handling errors (and recovering from issues) around network connectivity Conclusion The Salesforce Mobile SDK makes it tremendously easy to connect mobile devices with Salesforce data. In this post, you learned how to query and manipulate data from your phone, and saw the results reflected instantaneously on Salesforce. You also learned about Mobile Sync and its role in anticipating issues with connectivity. And yet, with all of this information, there’s still that the Salesforce Mobile SDK can do. Take a look at the on working with the SDK. Or, if you prefer to do more coding, there are to keep you busy. We can’t wait to see what you build! so much more complete documentation plenty of Trailhead tutorials

Building a Kotlin Mobile App with the Salesforce SDK: Synchronizing Data

Mastering Maps in Go: Everything You Need to Know

গো-তে মানচিত্র আয়ত্ত করা: আপনার যা জানা দরকার

Maps in Go meistern: Alles, was Sie wissen müssen

Dominar mapas en Go: todo lo que necesitas saber

Maîtriser les cartes en Go : tout ce que vous devez savoir

गो में मानचित्रों पर महारत हासिल करना: वह सब कुछ जो आपको जानना चाहिए

Go でマップをマスターする: 知っておくべきことすべて

Go로 지도 마스터하기: 알아야 할 모든 것

Dominando mapas em Go: tudo o que você precisa saber

Освоение карт в Go: все, что вам нужно знать

Go'da Haritalarda Uzmanlaşmak: Bilmeniz Gereken Her Şey

Làm chủ bản đồ trong Go: Mọi thứ bạn cần biết

掌握 Go 中的 Maps：你需要知道的一切

The Problem Periodically, when you are developing a Golang application, there is a need to store some data in memory using a map data structure. At the same time, the application can concurrently process a large number of requests and use the map in several goroutines concurrently. If you do not use any mechanisms of synchronization, the code fails with panic in runtime in that case. It is important to think of concurrent access to the map and data races. In this article, I want to consider several ways to solve this problem. Golang has built-in synchronization primitives and channels that can be used for that. Depending on the specific case, you can use different approaches. I am going to create the call counter which is a simple component that counts the number of times a method is called and the counters will be stored in a map. To begin with, let's define a simple interface that will have two methods. CallCounter The method will update the counter when the method is called, and the method will return the current value for the given method name. Call Count package callcounter

type CallCounter interface {
	Call(name string)
	Count(name string) int64
} Now, let's consider different implementations. sync.Mutex is a mutual exclusion lock. It is a synchronization primitive that allows concurrent goroutines to access shared data safely. A mutex ensures that only one goroutine can access the shared data at a time, preventing data races and other concurrency problems. sync.Mutex To use a , you must first lock it before accessing the map to shared data. Once you are finished accessing the shared data, you must unlock the mutex. If another goroutine tries to lock the mutex while it is already locked, it will be blocked until the mutex is unlocked. sync.Mutex Here is an implementation using : sync.Mutex package callcounter

import (
	"sync"
)

type CallCounterMutex struct {
	sync.Mutex
	counters map[string]int64
}

func NewCallCounterMutex() *CallCounterMutex {
	c := CallCounterMutex{
		counters: make(map[string]int64),
	}

	return &c
}

func (c *CallCounterMutex) Call(name string) {
	c.Lock()
	c.counters[name]++
	c.Unlock()
}

func (c *CallCounterMutex) Count(name string) int64 {
	c.Lock()
	count := c.counters[name]
	c.Unlock()

	return count
} sync.RWMutex is a read-write mutual exclusion lock. It is a synchronization primitive that allows multiple goroutines to concurrently read shared data, but only one goroutine to write shared data at a time. This is useful for situations where you need to allow concurrent reads, but not concurrent writes to shared data. sync.RWMutex To use a , you must first lock it for reading and writing using the and methods, respectively. Once you are finished accessing the shared data, you must unlock the mutex using the or methods, respectively. sync.RWMutex RLock Lock RUnlock Unlock If another goroutine tries to lock the mutex for reading while it is locked for writing, it will be blocked until the mutex is unlocked. Similarly, if another goroutine tries to lock the mutex for writing while it is locked for reading, it will be blocked until the mutex is unlocked. Here is an implementation using : sync.RWMutex package callcounter

import (
	"sync"
)

type CallCounterRWMutex struct {
	sync.RWMutex
	counters map[string]int64
}

func NewCallCounterRWMutex() *CallCounterRWMutex {
	c := CallCounterRWMutex{
		counters: make(map[string]int64),
	}

	return &c
}

func (c *CallCounterRWMutex) Call(name string) {
	c.Lock()
	c.counters[name]++
	c.Unlock()
}

func (c *CallCounterRWMutex) Count(name string) int64 {
	c.RLock()
	count := c.counters[name]
	c.RUnlock()

	return count
} sync.Map is a concurrent map implementation in Golang. It is a specialized map implementation that provides a concurrent, thread-safe map. It is specifically designed for use cases where the entry set of the map is stable over time, such as caches. sync.Map is a safe map, meaning that it can be accessed by multiple goroutines concurrently without the risk of race conditions or data corruption. It is also a fast map, with amortized constant-time loads, stores, and deletes. sync.Map Here is an implementation using : sync.Map package callcounter

import (
	"sync"
	"sync/atomic"
)

type CallCounterMap struct {
	sync.Map
}

func NewCallCounterMap() *CallCounterMap {
	c := CallCounterMap{}

	return &c
}

func (c *CallCounterMap) Call(name string) {
	value := int64(1)
	count, loaded := c.LoadOrStore(name, &value)
	if loaded {
		atomic.AddInt64(count.(*int64), int64(value))
	}
}

func (s *CallCounterMap) Count(name string) int64 {
	count, ok := s.Load(name)
	if ok {
		return atomic.LoadInt64(count.(*int64))
	}

	return 0
} Channels Channels are a powerful tool for communicating and synchronizing between concurrent goroutines. They are typed conduits through which you can send and receive values. To create a channel, you use the function. The function takes two arguments: the type of the values that the channel will transmit and the capacity of the channel. The capacity of the channel is the maximum number of values that the channel can store without blocking the sender. make make Channels allow us to write the code in a way where only one goroutine reads or writes to the map. Here is an implementation using channels: package callcounter

import "context"

type CallCounterChannels struct {
	counters map[string]int64
	call     chan string
	count    chan string
	result   chan int64
}

func NewCallCounterChannels(ctx context.Context) *CallCounterChannels {
	c := CallCounterChannels{
		counters: make(map[string]int64),
		call:     make(chan string),
		count:    make(chan string),
		result:   make(chan int64),
	}

	go func() {
		for {
			select {
			case <-ctx.Done():
				return
			case name := <-c.call:
				c.counters[name]++
			case name := <-c.count:
				c.result <- c.counters[name]
			}
		}
	}()

	return &c
}

func (c *CallCounterChannels) Call(name string) {
	c.call <- name
}

func (c *CallCounterChannels) Count(name string) int64 {
	c.count <- name

	return <-c.result
} Mutex Based on a Channel Also, Golang allows us to implement a simple mutex using channels. We need to use a buffered channel for that. A buffered channel in Golang is a channel that can store a limited number of values without blocking the sender. This is in contrast to an unbuffered channel, which can only store one value at a time and will block the sender if there is no receiver ready to receive the value. Buffered channels are created by passing an additional capacity parameter to the function. This parameter specifies the maximum number of values that the channel can store. We need to create a buffered channel that can store exactly one value. make It will allow us to use this channel to lock and unlock goroutines because when the buffered channel is full, it blocks other goroutines from writing into it, and they will wait until it is free. Here is an implementation using a buffered channel: package callcounter

type CallCounterChannelMutex struct {
	counters map[string]int64
	mutex    chan struct{}
}

func NewCallCounterChannelMutex() *CallCounterChannelMutex {
	c := CallCounterChannelMutex{
		counters: make(map[string]int64),
		mutex:    make(chan struct{}, 1),
	}

	return &c
}

func (c *CallCounterChannelMutex) Call(name string) {
	c.mutex <- struct{}{}
	c.counters[name]++
	<-c.mutex
}

func (c *CallCounterChannelMutex) Count(name string) int64 {
	c.mutex <- struct{}{}
	count := c.counters[name]
	<-c.mutex
	return count
} Comparing and Testing Now, let's write a simple test to ensure that our code is correct, concurrent safe, and does not have data races. We will also write some benchmarks and compare the performance of different approaches. package callcounter_test

import (
	"callcounter"
	"context"
	"fmt"
	"sync"
	"testing"

	"github.com/stretchr/testify/assert"
)

func TestCallCounter(t *testing.T) {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	tt := []struct {
		name    string
		counter callcounter.CallCounter
		calls   []int
	}{
		{
			name:    "mutex",
			counter: callcounter.NewCallCounterMutex(),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "rwmutex",
			counter: callcounter.NewCallCounterRWMutex(),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "map",
			counter: callcounter.NewCallCounterMap(),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "channels",
			counter: callcounter.NewCallCounterChannels(ctx),
			calls:   []int{0, 1, 3, 100},
		},
		{
			name:    "mutex based on a channel",
			counter: callcounter.NewCallCounterChannelMutex(),
			calls:   []int{0, 1, 3, 100},
		},
	}

	for _, tc := range tt {
		for _, calls := range tc.calls {
			testName := fmt.Sprintf("%s %d calls", tc.name, calls)

			t.Run(testName, func(t *testing.T) {
				wg := sync.WaitGroup{}
				for i := 0; i < calls; i++ {
					wg.Add(1)

					// Run in goroutine to make sure
					// there is no any issue with concurrent counter.
					go func() {
						defer wg.Done()

						tc.counter.Call(testName)
					}()
				}

				wg.Wait()
				assert.Equal(t, int64(calls), tc.counter.Count(testName))
			})
		}
	}
}

var result int64

func BenchmarkCallCounter(b *testing.B) {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	tt := []struct {
		name    string
		counter callcounter.CallCounter
	}{
		{
			name:    "mutex",
			counter: callcounter.NewCallCounterMutex(),
		},
		{
			name:    "rwmutex",
			counter: callcounter.NewCallCounterRWMutex(),
		},
		{
			name:    "map",
			counter: callcounter.NewCallCounterMap(),
		},
		{
			name:    "channels",
			counter: callcounter.NewCallCounterChannels(ctx),
		},
		{
			name:    "mutex based on a channel",
			counter: callcounter.NewCallCounterChannelMutex(),
		},
	}

	var count int64

	for _, tc := range tt {
		b.Run(tc.name, func(b *testing.B) {
			wg := sync.WaitGroup{}
			for i := 0; i < b.N; i++ {
				wg.Add(1)
				go func() {
					defer wg.Done()

					tc.counter.Call("call_name")
				}()

				wg.Add(1)
				go func() {
					defer wg.Done()

					// Always record the result of Count to prevent
					// the compiler eliminating the function call.
					count = tc.counter.Count("call_name")
				}()
			}

			wg.Wait()

			// Always store the result to a package level variable
			// so the compiler cannot eliminate the Benchmark itself.
			result = count
		})
	}
} Let's run the tests using the flag : --race $ go test --race -v .
=== RUN   TestCallCounter
=== RUN   TestCallCounter/mutex_0_calls
=== RUN   TestCallCounter/mutex_1_calls
=== RUN   TestCallCounter/mutex_3_calls
=== RUN   TestCallCounter/mutex_100_calls
=== RUN   TestCallCounter/rwmutex_0_calls
=== RUN   TestCallCounter/rwmutex_1_calls
=== RUN   TestCallCounter/rwmutex_3_calls
=== RUN   TestCallCounter/rwmutex_100_calls
=== RUN   TestCallCounter/map_0_calls
=== RUN   TestCallCounter/map_1_calls
=== RUN   TestCallCounter/map_3_calls
=== RUN   TestCallCounter/map_100_calls
=== RUN   TestCallCounter/channels_0_calls
=== RUN   TestCallCounter/channels_1_calls
=== RUN   TestCallCounter/channels_3_calls
=== RUN   TestCallCounter/channels_100_calls
=== RUN   TestCallCounter/mutex_channel_0_calls
=== RUN   TestCallCounter/mutex_channel_1_calls
=== RUN   TestCallCounter/mutex_channel_3_calls
=== RUN   TestCallCounter/mutex_channel_100_calls
--- PASS: TestCallCounter (0.01s)
    --- PASS: TestCallCounter/mutex_0_calls (0.00s)
    --- PASS: TestCallCounter/mutex_1_calls (0.00s)
    --- PASS: TestCallCounter/mutex_3_calls (0.00s)
    --- PASS: TestCallCounter/mutex_100_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_0_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_1_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_3_calls (0.00s)
    --- PASS: TestCallCounter/rwmutex_100_calls (0.00s)
    --- PASS: TestCallCounter/map_0_calls (0.00s)
    --- PASS: TestCallCounter/map_1_calls (0.00s)
    --- PASS: TestCallCounter/map_3_calls (0.00s)
    --- PASS: TestCallCounter/map_100_calls (0.00s)
    --- PASS: TestCallCounter/channels_0_calls (0.00s)
    --- PASS: TestCallCounter/channels_1_calls (0.00s)
    --- PASS: TestCallCounter/channels_3_calls (0.00s)
    --- PASS: TestCallCounter/channels_100_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_0_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_1_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_3_calls (0.00s)
    --- PASS: TestCallCounter/mutex_channel_100_calls (0.00s)
PASS
ok      github.com/ivanlemeshev/callcounter     1.014s Now, let’s run benchmark tests: $ go test -bench=. -benchmem -count 1
goos: linux
goarch: amd64
pkg: github.com/ivanlemeshev/callcounter
cpu: AMD Ryzen 7 5800H with Radeon Graphics
BenchmarkCallCounter/mutex-16            2054628               605.1 ns/op            79 B/op          2 allocs/op
BenchmarkCallCounter/rwmutex-16          1000000              1057 ns/op             174 B/op          2 allocs/op
BenchmarkCallCounter/map-16              3605562               363.4 ns/op            80 B/op          4 allocs/op
BenchmarkCallCounter/channels-16          593912              2483 ns/op             273 B/op          3 allocs/op
BenchmarkCallCounter/mutex_channel-16     492544              2310 ns/op             268 B/op          3 allocs/op
PASS
ok      github.com/ivanlemeshev/callcounter     7.923s The benchmark results show that the Mutex-based implementation is the fastest and most efficient implementation. It has the lowest operation time and the lowest memory allocation. The RWMutex-based implementation is a good alternative if you need to support concurrent reads and writes to the call counter. The map-based implementation is a good alternative if you need a fast call counter implementation, and you don't need to support concurrent writes. The channel-based implementation is the slowest and least efficient implementation in our case. Summary The results show that depending on the requirements, you should choose the approach that is most suitable for your particular case. It may be a bad idea to use only channels all the time. , , , and channels are synchronization primitives in Golang that can be used to protect shared data and coordinate the execution of goroutines. However, they have different strengths and weaknesses and should be used in different situations. sync.Mutex sync.RWMutex sync.Map Mutexes are a good choice for protecting shared data frequently accessed by concurrent goroutines. For example, you might use a mutex to protect a shared counter or a map. Channels are a good choice for coordinating the execution of goroutines that need to communicate with each other or synchronize their execution. For example, you might use channels to implement a producer-consumer pattern or to coordinate the execution of a pipeline of goroutines. can be used when you need a concurrent-safe map that is optimized for read-heavy workloads. is a specialized map implementation that provides a concurrent, thread-safe map. It is specifically designed for use cases where the entry set of the map is stable over time, such as caches. sync.Map sync.Map

How to Use Maps Safely in Go

How to Build a Twitter Bot with IPFS Cluster

It has become a tradition for Google to release the source code of Android app after several weeks of the event. I/O event This annual release is done to demonstrate best practices for app development. Developers can take a look at the code to get a better understanding of Google’s best practices for . Android App Development App Architecture Google’s I/O 2018 app represents a complete rewrite of the application. The app has moved from ContentProvider+SyncAdapter architecture to Architecture Components. It’s the Google’s Android Team current recommendation for the developing modern apps for Android. Google has used for the rewrite of the application. Kotlin Here is the general overview of the app’s architecture – Repository layer is used for handling data operations. Data comes from different data sources – – User Data is stored in Cloud Firestore (either remotely or in the local cache) – User settings and preferences are stored in SharedPreferences – Conference Data is stored remotely and is fetched and stored in the memory Repository modules are responsible for handling all the data operations. is used for dependency injection. Dagger2 is used for basic instrumentation tests and and for unit testing. Espresso JUnit Mockito Firebase The has now matured and the use of Firebase technologies has now increased. Following are the Firebase components used in I/O 2018 – Firebase platform FIREBASE CLOUD FIRESTORE It is the Google’s source for all user data FIREBASE CLOUD FUNCTIONS Firebase Cloud Functions are used to run backend code. The reservation function, checking user’s status, checking space availability all depends upon on Cloud Functions. FIREBASE CLOUD MESSAGING Cloud Messaging is used to inform app about any sort of changes in conference data using a ping-and-fetch model. FIREBASE REMOTE CONFIG Remote Config is used to inform users about WiFi information, conference schedule etc in a lightweight manner. Kotlin Google made the choice of rewriting the app from scratch in Koltin to bring the modern Android architecture. Using Kotlin for the rewrite is an easy choice because – – Kotlin’s syntax is expressive, concise, and powerful – Support for safety features including nullability and immutability – Enhanced Functionality using Android Ktx extensions Material Theming At I/O 2018, The Material Design team announced Material Theming which give apps the ability to customize Material Design to bring more personalization of their product’s brand. As the app was released before Material Theming, so they could not use all of the new components but managed to sneak a few including a new Bottom App Bar with inset Floating Action Button. The app is available for developers on Github . Learn more on our Website — VT Netzwelt

Google Releases Source Code For I/O App 2018

So recently gave a talk at about and he mentions that in order to get feature in Go, we must first show enough of why its a problem, so it gets attention from the Go team, helping them understand our point of view, we need to convince them that is a real problem and that is the best possible solution. Russ Cox Gophercon “ The Future of Go ”, X examples Y (the community’s) Y X probably To accomplish that, we need to create the so called , basically posts about the described above. So here we are. Experience Reports Also, I would like to point out that this post does cover any concrete implementation examples but rather give a brief look at what some pkgs of the may look like if something like generics were implemented. NOT stdlib The Problem I like to describe the problem as: The lack of generics / way of declaring dynamic behavior while keeping type safety, forces the users to grow their code base by either: The use of code generation that just makes the code way more unreadable for the end-user and creates confusion due to various functions with similar names instead of having just one. — Sacrifice code readability and API complexity for type safety — tools The use of to avoid numerous functions with similar names but at the cost of type casting/assertion almost everywhere. — Sacrifice type safety for readability and reduced user API — interface{} (empty interfaces) In either case we’re making use of code that doesn’t actually belongs to our applications’s core logic, but rather acts like the glue that’s needed for pretty much every project. A little example I know what you’re thinking, just hold on for a second, this is from the pkg and it serves as a perfect example for the second from above. If we look deeper into the code that deals with that variable we encounter something like this… “This is not from the stdlib…” discordgo case handler Not so pretty, right? And there are to handle a , and just so it stays in mind, here the pkg maintainers decided to expose 1 function and leave the of type checking for themselves instead of exposing to the user. And all of that to add a handler. 37 more cases just single variable hard work 44 different functions with similar names simple The stdlib In the stdlib you can find some pkgs that could reduce their API’s immensely if and just if something like generics existed for Go, examples: sync/atomic Contains 29 pkg funcs with names like , , where could be , , , and so on . . . Add T CompareAndSwap T T Int32 Int64 Uint32 Uint64 Almost literally the whole pkg API would be: That just went from to . 29 functions with larger names just 5 with shorter names sync.Map (Go 1.9+) Yep, this awesome concurrent map is coming! with everywhere . . . interface{} In this case, the benefit is type safety since the API is simple enough. only math/rand Very similar to the case, instead of what about: sync/atomic Int, Intn, Int31, Int31n Same treatment goes for the type. rand.Rand math/big Maybe convert the , and types into a general type and compute the operations depending on the generic. Float Int Rat Number And some others applicable cases are: container/list container/heap container/ring could be more, just haven’t done enough research I also think that for example, let’s say we have this pretty common piece of code: I believe if there were generics this kind of operations could be improved /optimized at compile time since the compiler what the format of the data looks like. Example below. knows Same for all encoding/decoding stuff such as , is not included since all records are always returned in which means no reflection/type assertion at all. encoding/xml encoding/csv [][]string What I’m trying to say is that the stdlib be reduced and simplified in numerous places with the help of generics, and of course third-party pkgs as well. I hope this post at least serves as a clear example of what can be done with generics. CAN

Generics on Go’s stdlib

Stories, News & Mentions about SYNCMAMA

Syncmama’s Stories on HackerNoon