Syncly

syncly

Is Your Apache Ni-Fi Ready for Production?

ON THE PLAINS AND VALLEYS OF CHILE:—SALIFEROUS SUPERFICIAL DEPOSITS

I opened my Twitter account more than 13 years ago, in August 2009. For 12 years, I kept focusing on professional-related content: Java, the JVM, programming, etc. I built my audience, trying to promote good technical content, either my own or stuff that I enjoyed reading. Then, on February 24th, Russia invaded Ukraine. My first visit to Ukraine was in 2014, just after the Maidan revolution. During eight years, I returned there often and made plenty of friends. Of course, I wanted to support them and started to use my Twitter account to fight Russian disinformation. I discovered how toxic Twitter could be after having stayed out of politics since the beginning: bad faith, logical fallacies, flat-out lies, reverse accusations, personal attacks, etc. With the acquisition of Twitter by Elon Musk, I’m afraid it’s going to get much worse — case in point: Some (most?) people I know planned or already had moved away. The target seems to be Mastodon, an alternate decentralized Open Source using the protocol: ActivityPub Mastodon is free and open-source software for running self-hosted social networking services. It has microblogging features similar to the Twitter service, which are offered by a large number of independently run Mastodon nodes (technically known as instances), each with its own code of conduct, terms of service, privacy options, and moderation policies. Each user is a member of a specific Mastodon instance (also called a server), which can interoperate as a federated social network, allowing users on different nodes to interact with each other. This is intended to give users the flexibility to select a server whose policies they prefer, but keep access to a larger social network. Mastodon is also part of the Fediverse ensemble of server platforms, which use shared protocols allowing users to also interact with users on other compatible platforms, such as PeerTube and Friendica. — https://en.wikipedia.org/wiki/Mastodon_(software) Forewarned is forearmed. I plan to stay on Twitter as long as possible while building up my Mastodon account with the same content. Then, if (when?) all hell breaks loose, I can just jump ship. Evaluating the Alternatives Let’s state things clearly: I believe I’m a good developer because I’m lazy. There’s no way I’m going to copy-paste content on both channels. Plus, I’m using Twitter’s scheduling feature, so I need something else. I’m one of many who want to keep a foot in each realm. For example, I found that Martin Fowler is also following . However, his approach is “specific”: the same strategy One of the main things I wanted to do with Mastodon was to replicate my twitter feed there, so that folks who would rather follow me on Mastodon could get everything. To do this, I used moa.party. You have to give it credentials to access both your Twitter and Mastodon feeds, which is a little worrisome, but my Mastodon-aware colleagues have used it without problems. There’s no way I’d give my credentials to a third party! I searched further and found this gem: This tool synchronizes posts from Mastodon to Twitter and back. It does not matter where you post your stuff — it will get synchronized to the other! — Mastodon Twitter Sync It looked exactly what I was searching for! Mastodon Twitter Sync The tool provides two execution options: A Docker image Run from source — Rust The has no tags, save , and I had some issues mapping volumes. Docker image latest Hence, I decided to run from source. Again, I'm lazy and don't want to run the tool manually. I've been using GitHub Actions for a couple of years to schedule my scripts. Let’s start with the following: name: Sync Twitter to and from Mastodon
on:
  schedule:
    - cron: "24 */2 * * *"                               #1
  workflow_dispatch:
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the synchronization code         #2
        uses: actions/checkout@v3
        with:
          repository: klausi/mastodon-twitter-sync
      - name: Install Rust                               #3                            
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          profile: minimal                               #4
      - name: Execute synchronization                    #5
        uses: actions-rs/cargo@v1
        with:
          command: run
          args: --release Schedule every two hours, 24 minutes after the hour. Check out the sync project’s code. Install the Rust toolchain. The toolchain comes in different flavors called . For scripting, is enough, providing only , , and profiles minimal rustc rust-std cargo. Run the code Managing Credentials Spoiler: the workflow doesn’t work. By default, the code runs interactively: it will ask for credentials to connect to both Twitter and Mastodon. Alternatively, the project accepts a configuration file containing all data — . mastodon-twitter-sync.toml My advice is to run the project interactively locally once. If the TOML file doesn’t exist, the executable will ask for credentials and generate a new one containing them. But we shouldn’t add a file containing credential data in plain text on a Git repo. Instead, we shall: Encrypt the file. Add and commit the encrypted file. During workflow run, decrypt the file using a GitHub Action secret. jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Install GPG to decrypt the configuration file
        run: sudo apt-get update && sudo apt-get install -y gnupg
      - name: Decrypt the configuration file
        run: gpg --quiet --batch --yes --decrypt --passphrase="$GPG_PASSPHRASE" --decrypt mastodon-twitter-sync.toml.gpg > mastodon-twitter-sync.toml 
        env:
          GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }} At this point, we have mixed the Rust source code with our configuration file in the same Git repository. Handling such a project involves a lot of , which I want to avoid. Let's keep the code separate with its dedicated lifecycle locally. git rebase mastodon-twitter-sync-job               #1
|_ .github
|  |_ workflows
|    |_ sync.yml                        #2
|_ mastodon-twitter-sync.toml.gpg       #3

mastodon-twitter-sync                   #4
|_ src
|_ ... My project GitHub action Encrypted credential file Independent sync project We need to change how we check out the code: jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repo itself
        uses: actions/checkout@v3
        with:
          path: job
      - name: Check out the synchronization code
        uses: actions/checkout@v3
        with:
          repository: klausi/mastodon-twitter-sync
          path: code When we run the workflow, the layout is the following: |_ job
|  |_ .github
|  |  |_ workflows
|  |    |_ sync.yml
|  |_ mastodon-twitter-sync.toml.gpg
|
|_ code
|  |_ src
|  |_ ... Henceforth, we should update the decrypting and run the steps accordingly: jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Decrypt the configuration file
        run: |
          gpg --quiet --batch --yes --decrypt --passphrase="$GPG_PASSPHRASE"
              --decrypt job/mastodon-twitter-sync.toml.gpg > mastodon-twitter-sync.toml #1
        env:
          GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
      - name: Execute synchronization
        uses: actions-rs/cargo@v1
        with:
          command: run
          args: --manifest-path=./code/Cargo.toml --release                             #2 Decrypt from the subfolder in the current root folder. job Run in the current folder using the subfolder. code Sync Only Once The project creates a file that contains all previously synced content to avoid duplicating the same content during each execution. We need to take it into account: post_cache.json jobs:
  sync:
    runs-on: ubuntu-latest
      - name: Update post cache
        run: >
          cp ./post_cache.json ./job/ 2>/dev/null || :    #1
      - name: Commit and push post cache
        uses: EndBug/add-and-commit@v7                    #2
        with:
          cwd: './job'
          add: post_cache.json
          default_author: github_actions
          message: Update post cache Copy the in the subfolder. Only succeed the step if the job synchronizes no content, and the file is generated. post_cache.json job Commit back the file if it has changed. Workflow Optimization In the current state, each run downloads the dependencies and compiles the project, even though the source code stays the code; it’s highly inefficient. The platform provides a generic . However, I found , a Rust-specific one that provides appropriate defaults for Rust. Let’s use it to cache the dependencies and the executable across workflow executions (provided some parameters stay the same): caching GitHub Action rust-cache jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable
          profile: minimal
      - name: Cache executable             #1
        uses: Swatinem/rust-cache@v2
        with:
          workspaces: code                 #2 Must be installed after Rust install, as the cache key contains Rust-specific data Cache artifacts located in the subfolder code Final Notes With this setup, I need to update the repo with the new JSON cache file before I commit any change to the workflow. I could create a dedicated repo for it to improve the situation, but it’s good enough for now. The connection to Mastodon is fickle; a lot of actions fail with the following message: Error connecting to Mastodon: Http(
    reqwest::Error {
        kind: Request,
        url: Url {
            scheme: "https",
            cannot_be_a_base: false,
            username: "",
            password: None,
            host: Some(
                Domain(
                    "mastodon.top",
                ),
            ),
            port: None,
            path: "//api/v1/accounts/verify_credentials",
            query: None,
            fragment: None,
        },
        source: TimedOut,
    },
) It’s not an issue ; it just means that synchronization lags. Should I move to a more reliable instance or even host my own? per se So far, I’ve kept Twitter as my source of truth. I post content there, and it should appear on Mastodon. However, synchronization should happen both ways. Once I make Mastodon my main channel, I don’t need to change the above work. Conclusion Twitter’s new owner claims to promote “comedy” but suspends accounts that make fun of him. At the same time, he claims to be a proponent of free speech but confuses opinion with information. The advertising market may curb his misguided views, but it’s still being determined. In the meantime, I’m not willing to sit idly. Mastodon is gaining a lot of momentum. In this post, I’ve explained how you can cross the chasm while still keeping your presence on Twitter until you don’t want to. Thanks to for their fantastic sync project and patience with my stumbling. klausi The source code is available on GitHub: https://github.com/nfrankel/mastodon-twitter-sync-job?embedable=true To go further: Me on Mastodon Martin Fowler’s adventures in Mastodon Mastodon documentation Moa bridge (be careful!) Mastodon Twitter Sync Originally published at on December 11th, 2022 A Java Geek

How to Move Away From Twitter

Cómo alejarse de Twitter

Comment s'éloigner de Twitter

ट्विटर से दूर कैसे जाएँ

Twitterから離れる方法

Como se afastar do Twitter

Làm thế nào để thoát khỏi Twitter

如何远离 Twitter

Write Code to Build Your Own Playlist and Throw Away Spotify

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

If you have ever been on a job hunt for a software developer position, you would have come across the so-called LeetCode style interviews. Despite the fact that most of us don’t have to at our actual job, that is how most coding/technical interviews are conducted at big tech companies like Google and Microsoft. Yes, even at the likes of (except for Stripe, because they are cool) and startups. invert a Binary Tree unicorns In this post, I’ll be writing about the thought process of how I came about building and deploying a very simple JavaScript app for free with . If you simply want to deploy and use the app on your own, check out the repository . Cloudflare Worker here TL;DR How to get the Daily LeetCoding Challenge question using LeetCode API Creating a Todoist task using Todoist API Schedule our app to run daily using Cloudflare Worker ScheduledEvent API How to test a Cloudflare Worker Cron trigger locally with Miniflare Problem Statement For a year now, I have been trying to make it a habit to solve the Daily LeetCoding Challenge (which I’m still struggling with). As I am using as my main productivity tool of choice, I have a daily task that looks just like this: Todoist As a lazy person, having to check every time I want to practice is too much of a hassle. So then I thought, why not just sync the Daily LeetCoding Challenge to my Todoist every day? leetcode.com Requirements Let’s start by defining what I want the app to do: Get Daily LeetCoding Challenge question Ability to create a new task on my Todoist account Sync new Daily LeetCoding Challenge question on time The app has to sync on time for free every day Let’s start! LeetCode API Like any sane person would do, the first thing I did was to do some research. By research, I meant I started to Google for information. The first thing I did was to immediately Google for “leetcode API”, looking for the official API documentation. Official API documentation To my surprise, there wasn’t any official LeetCode API documentation available. While there is a couple of unofficial LeetCode API repositories on GitHub, I would rather not use any unofficial API due to reliability concerns (poorly maintained, outdated, etc.). The Good Ol’ DevTool inspection The second thing that immediately came to my mind was to inspect the network request being made while visiting the site . https://leetcode.com/problemset/all/ With this, I was able to figure out the exact API called to query for the Daily LeetCoding Challenge — done. Here’s the GraphQL request body: # HTTP POST to https://leetcode.com/graphql
query questionOfToday {
    activeDailyCodingChallengeQuestion {
        date
        userStatus
        link
        question {
            acRate
            difficulty
            freqBar
            frontendQuestionId: questionFrontendId
            isFavor
            paidOnly: isPaidOnly
            status
            title
            titleSlug
            hasVideoSolution
            hasSolution
            topicTags {
                name
                id
                slug
            }
        }
    }
} You can use the command below to try it out yourself: curl curl --request POST \
  --url https://leetcode.com/graphql \
  --header 'Content-Type: application/json' \
  --data '{"query":"query questionOfToday {\n\tactiveDailyCodingChallengeQuestion {\n\t\tdate\n\t\tuserStatus\n\t\tlink\n\t\tquestion {\n\t\t\tacRate\n\t\t\tdifficulty\n\t\t\tfreqBar\n\t\t\tfrontendQuestionId: questionFrontendId\n\t\t\tisFavor\n\t\t\tpaidOnly: isPaidOnly\n\t\t\tstatus\n\t\t\ttitle\n\t\t\ttitleSlug\n\t\t\thasVideoSolution\n\t\t\thasSolution\n\t\t\ttopicTags {\n\t\t\t\tname\n\t\t\t\tid\n\t\t\t\tslug\n\t\t\t}\n\t\t}\n\t}\n}\n","operationName":"questionOfToday"}' Enough talking, let’s start to write some code that does exactly what we went through: // Just some constants
const LEETCODE_API_ENDPOINT = 'https://leetcode.com/graphql'
const DAILY_CODING_CHALLENGE_QUERY = `
query questionOfToday {
	activeDailyCodingChallengeQuestion {
		date
		userStatus
		link
		question {
			acRate
			difficulty
			freqBar
			frontendQuestionId: questionFrontendId
			isFavor
			paidOnly: isPaidOnly
			status
			title
			titleSlug
			hasVideoSolution
			hasSolution
			topicTags {
				name
				id
				slug
			}
		}
	}
}`

// We can pass the JSON response as an object to our createTodoistTask later.
const fetchDailyCodingChallenge = async () => {
    console.log(`Fetching daily coding challenge from LeetCode API.`)

    const init = {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ query: DAILY_CODING_CHALLENGE_QUERY }),
    }

    const response = await fetch(LEETCODE_API_ENDPOINT, init)
    return response.json()
} Task “Get Daily LeetCoding Challenge question” — checked. Todoist API Like what we did in the previous step, I was able to find the for Todoist. Typically, the first section that I always look for in API documentation is the section, especially when you want to perform create/update/delete operations on an app. official API documentation Authorization In short, authorization was pretty straightforward for Todoist: Get your API token Whenever you make a request, attach to your HTTP request header Authorization: Bearer xxx-your-todoist-api-token-xxx Here’s an example of what the curl command to create a new task on Todoist would look like: curl --request POST \
 --url 'https://api.todoist.com/rest/v1/tasks?=' \
 --header 'Authorization: Bearer xxx-your-todoist-api-token-xxx' \
 --header 'Content-Type: application/json' \
 --data '{
"content": "Buy a jar of peanut butter",
"due_string": "Today"
}' Code Writing a function that does what we said is relatively easy, it looks something like this: const TODOIST_API_ENDPOINT = "https://api.todoist.com/rest/v1";

// Passing in the `question` object from fetchDailyCodingChallenge function
const createTodoistTask = async (question) => {
    const questionInfo = question.data.activeDailyCodingChallengeQuestion;

    const questionTitle = questionInfo.question.title;
    const questionDifficulty = questionInfo.question.difficulty;
    const questionLink = `https://leetcode.com${questionInfo.link}`;

    console.log(`Creating Todoist task with title ${questionTitle}.`);

    const body = {
        content: `[${questionTitle}](${questionLink})`,
        description: `Difficulty: ${questionDifficulty}`,
        due_string: "Today",
        priority: 4,
    };

    const init = {
        method: "POST",
        body: JSON.stringify(body),
        headers: {
            "Content-Type": "application/json",
            Authorization: `Bearer ${TODOIST_API_TOKEN}`, // Set at environment variable
        },
    };

    const response = await fetch(`${TODOIST_API_ENDPOINT}/tasks`, init);
    return response.json();
}; Task “Create a new task on my Todoist account” — done. Cloudflare Worker And we’re down to our one final task — running/automating the 2 tasks above every day, for free. The first thing that came to my mind was Cron job. So, I immediately started looking for free solutions on the Internet. After spending a couple of hours doing some homework, I came across Cloudflare Worker, and I figured to give them a try. It runs on V8 JavaScript, not Node.js This is probably one of the most common misconceptions . As the worker’s environment is not in Node.js, a lot of packages (e.g. ) that are running on Node.js would simply not work. about Cloudflare Worker npm install some-node-package Tip: Check out the supported packages and libraries . here Lucky for us, we only need to use the JavaScript built-in API. fetch More code Starting a Cloudflare Worker project is dead simple ( ), basically: reference Install the Wrangler CLI using npm install -g @cloudflare/wrangler Run wrangler generate <your-project-name> <worker-template> The entry point is function. For our use case, we will be using the API where we simply have to change our event from to addEventListener ScheduledEvent "fetch" "scheduled" Let’s stitch everything together: // Move the constants to const.js

const syncLeetCodeCodingChallenge = async (event) => {
    const question = await fetchDailyCodingChallenge();
    await createTodoistTask(question);
};

addEventListener("scheduled", (event) => {
    // Change 'fetch' to 'scheduled'
    event.waitUntil(syncLeetCodeCodingChallenge(event));
}); Next, we would simply need to modify the wrangler.toml as below: name = "<your-project-name>"
type = "webpack"

...

[triggers]
crons = ["1 0 * * *"] With the setting above, the worker will run every day at and sync the Daily LeetCoding Challenge to your Todoist. 00:01 UTC That’s all! Moving on to testing. How to test Cloudflare workers locally In order to try out the Cron triggers locally, we would need to install the . After installation, you may run your worker using: Miniflare CLI # At terminal 1
miniflare

# At terminal 2
curl "http://localhost:8787/.mf/scheduled" If you see a new task is created on your Todoist, you have made it! Deployment No side project is ever done without hosting it. To deploy the app on your own immediately, check out the and use the button. If you’re interested in the know-how: project repository “Deploy with Workers” Create a Cloudflare account. Add using . You may find the newly added secret under 'Cloudflare Worker' → 'Settings' → 'Variables'. You can get your Todoist API token . TODOIST_API_TOKEN wrangler secret put TODOIST_API_TOKEN here Optional: This is only required for . Add into your GitHub repository secrets. You can create your API token from using the template. Wrangler actions CF_API_TOKEN https://dash.cloudflare.com/profile/api-tokens Edit Cloudflare Workers Finally, to publish any new changes to your Cloudflare Worker, run wrangler publish And we are finally done! Closing Thoughts Finally, there’s a lot more that we could have done, e.g.: Handling unanswered questions from previous days Making the app configurable/customizable for users Add tags to our task Allowing users to create a random LeetCode question as a task based on question tag I’m going to leave these features out for another day. While there is a lot of hate on coding interviews as such, I personally look at it this way — by learning some brain teasers, you probably get paid a lot more, so why not? It is really a matter of perspective. If you happen to enjoy doing them, that is even better. Personally, I don’t find as much joy doing LeetCode questions. Rather, I work on LeetCode problems as if I am lifting weights at the gym. While I don’t enjoy lifting weights, I do like reaping the benefits of it. That’s all for today. Let me know what are you building with Cloudflare Worker!

How to Keep Track of Daily LeetCode Challenges With Todoist and Cloudflare Worker

How We Localized Our Website in 9 Languages in Under a Week — And So Can You

Modern Binary Reverse-Engineering with node.js, for Elm

Stories, News & Mentions about SYNCLY

Syncly’s Stories on HackerNoon