But the moment they press the home button, everything stops. A sync that should have completed in the background never ran. A notification that should have fired didn't. A file upload that started while the user was in the app failed silently the moment they switched away.

Background execution on mobile is one of the most misunderstood topics in the entire mobile engineering space. Most developers treat it like a simple problem: just keep the code running in the background. The platforms treat it like a resource management problem that directly affects battery life, performance, and the overall health of the device.

Understanding how iOS and Android actually think about background work, and then understanding how Flutter sits on top of both, is what separates engineers who fight the platform from engineers who work with it.

This article covers exactly that. You'll understand the native mechanisms on both platforms, the Flutter packages that bridge them, and when to reach for each approach.

Table of Contents

• Why Background Execution is Hard

• How Flutter Runs in the Background

• iOS Background Execution

• Android Background Execution

• Flutter Implementation

• The Decision Framework

• Conclusion

Prerequisites

This article is written for mobile engineers building or maintaining production applications on iOS, Android, or Flutter. Before reading, you should be comfortable with:

• The basic lifecycle of a mobile app: what happens when the app moves between foreground, background, and suspended states

• General mobile development concepts: you have shipped or maintained at least one mobile application on any platform or framework

• Writing mobile applications in any framework: native iOS, native Android, Flutter, React Native, or any other mobile development stack

• Multithreading and concurrency in your programming language of choice: understanding how your language handles work that runs outside the main thread is the foundation of everything this article covers

If you're completely new to mobile development or have never had to think about threads and concurrent execution, start with those fundamentals first and return to this article when you are ready to think about production-grade background work.

Why Background Execution is Hard

When your app is in the foreground, the platform gives it essentially full access to CPU, network, and memory. The user is actively looking at the app. Battery drain is expected. Resource usage is justified.

The moment the app goes to the background, the calculus changes completely. There are potentially dozens of apps installed on the device. If every one of them ran freely in the background, the battery would drain in hours. The CPU would be constantly active. Memory would fill up. The device would become hot and slow.

Both iOS and Android made a decision early on that background execution is a privilege, not a right. Apps must earn the right to run in the background by declaring what they need and why. The platform then decides how, when, and for how long to grant that access.

iOS and Android approached this problem differently but have been converging toward the same model over time: declared, categorized, and constrained background work that the platform controls.

How Flutter Runs in the Background

Before looking at iOS and Android separately, you need to understand something fundamental about how Flutter works.

Flutter runs your Dart code in a single main isolate. This isolate is attached to the platform's main thread. It handles your UI, your business logic, everything. When the app goes to the background, this main isolate can be suspended at any time.

When background work needs to happen in Flutter, the platform doesn't wake your main isolate. It wakes a separate, independent Dart isolate specifically for background execution. This background isolate runs in complete isolation from the main isolate.

What This Means Practically:

The background isolate has no access to the widget tree. You can't call setState, update any UI, or use any widget or BuildContext. It's pure Dart execution with no UI layer.

The background isolate doesn't share memory with the main isolate. Any data you need in the background must be persisted to disk (shared preferences, local database, files) and read by the background isolate independently.

The background isolate must be a top-level function or a static method. It can't be an anonymous function or a method on a class instance. The platform needs to be able to call this function by name when waking the app.

Understanding this changes how you think about background work in Flutter. You aren't keeping your app running. You're registering a separate piece of Dart code that the platform can invoke on its own schedule, in its own isolated environment.

iOS Background Execution

What iOS Does to Your App

iOS manages your app through a set of clearly defined states.

When the user presses the home button, your app moves from foreground to background. iOS gives you a very brief window, typically five to ten seconds, to finish whatever you were doing. After that, your app is suspended. Suspended means completely frozen in memory. No Dart code runs. No network requests go out. The app exists in RAM but is essentially paused.

iOS can kill suspended apps at any time if it needs memory. When the user returns to your app, iOS either resumes it from suspension (fast) or relaunches it from scratch (slow). If your app was killed while suspended, the user won't know. The app just relaunches normally.

To do anything meaningful in the background on iOS, you must declare your intentions. iOS has a specific list of background capabilities, and your app must request exactly the ones it needs. Apple reviews these declarations during App Store submission.

BGTaskScheduler

BGTaskScheduler is the modern iOS API for scheduling background work. Introduced in iOS 13, it replaced older and less reliable approaches. It gives you two types of tasks.

BGAppRefreshTask is for short, periodic background work. Think of it as iOS giving your app a brief wake-up to check for new content and update its state. You get approximately 30 seconds. iOS decides when to run the task based on the user's usage patterns. If the user opens your app every morning at 8am, iOS learns this and tries to run your refresh task just before 8am so content is ready when they arrive.

BGProcessingTask is for longer, heavier work. Database migrations, large file processing, or ML model updates. You get several minutes. These tasks only run when the device is plugged in and ideally on WiFi. You get more time but no guarantees on when the task actually runs.

The rules iOS enforces are strict.

You must declare your task identifiers in Info.plist under BGTaskSchedulerPermittedIdentifiers before the app ships. If the identifier isn't declared there, the task will never run regardless of what your code does.

You must register your task handler before applicationDidFinishLaunching completes. This happens before Flutter even initializes. The workmanager package handles this automatically, but it's important to understand why.

Every task must call setTaskCompleted when it finishes. If you don't call this, iOS marks the task as failed and becomes increasingly reluctant to schedule future tasks.

You should always set an expiration handler. If iOS decides to kill your task early, it calls the expiration handler first, giving you a brief moment to clean up, save state, and mark the task as incomplete so it gets rescheduled.

iOS Background Modes

Beyond BGTaskScheduler, iOS has specific background modes for certain categories of apps. These are declared in Info.plist and enable continuous background execution for very specific purposes.

Audio and AirPlay keeps your app running as long as it's playing audio. The user sees now-playing controls on the lock screen. Podcast apps, music apps, and navigation apps with voice guidance use this. iOS is generous with this mode because the user clearly intends the audio to continue.

Location Updates allows continuous GPS access even when backgrounded. There are two levels. Significant location changes uses cell tower data and is battery-friendly. It fires when the device moves significantly, roughly 500 meters. Continuous location updates give precise GPS but drain battery. Apple scrutinizes location background mode during review. You need a genuine, user-facing reason.

Background Fetch is a legacy mechanism where iOS periodically wakes your app for a short window to fetch content. Unlike BGAppRefreshTask, this uses the older API. Most new apps should prefer BGTaskScheduler.

Remote Notifications with the content-available flag allows your server to trigger a brief background wake. When your server sends a silent push notification, iOS wakes your app to process it. This is how many apps stay current without constant polling.

The iOS Reality

iOS background execution is fundamentally about trust. Apple trusts your app with background time if you declare what you need, use it for the declared purpose, and respect the time limits.

Exceed your time limit and iOS terminates your app. Request background modes you don't actually need and App Store review will flag it. Use location in the background for purposes not evident to the user and you will face rejection.

The watchdog timer is real. iOS monitors background tasks actively. Tasks that run too long, use too much CPU, or behave unexpectedly get terminated. Build your background tasks to be fast, focused, and respectful of system resources.

Android Background Execution

What Android Does to Your App

Android manages process priority through a hierarchy. Foreground apps get the highest priority. Apps with running services get elevated priority. Background apps have lower priority. Empty processes and apps with no active components have the lowest priority.

When the system needs memory, it kills processes in order of priority, starting from the lowest. Your background app can be killed at any time. An app with a foreground service is much harder to kill. An active foreground app is essentially never killed by the system.

Android was historically more permissive than iOS. Early Android allowed apps to run services indefinitely in the background. This freedom was abused. Apps ran constantly even when the user hadn't interacted with them in weeks. Battery life suffered, and Android had to respond.

Starting with Android 8.0 Oreo, Google began restricting background services. Apps can no longer start background services when the app itself isn't in the foreground. Each subsequent Android version has tightened these restrictions further. Android is converging toward iOS's model of declared, constrained background work.

Foreground Services

A foreground service is the most reliable form of background execution on Android. It runs continuously and must display a persistent notification. The notification is mandatory. It's how Android communicates to the user that something is actively happening. The user can see it, expand it for details, and stop it if they choose.

Music players show the currently playing track with playback controls. Navigation apps show the current route with estimated arrival time. File upload apps show a progress bar. Fitness apps show elapsed time and current stats.

Android 14 introduced foreground service types. You must now declare what kind of foreground service you're running. The types are: mediaPlayback, location, dataSync, camera, microphone, phoneCall, remoteMessaging, shortService, health, and systemExempted. This is Android deliberately moving toward the iOS model of declared categories.

Foreground services are the right choice when the user expects something to be actively happening. Playing music. Navigating. Uploading a file. Anything where there is an ongoing activity that the user initiated and expects to continue.

WorkManager

WorkManager is Google's recommended solution for deferrable, guaranteed background work. The key characteristics that define it are important to understand.

Guaranteed means your work will eventually run. Even if the app exits, the user restarts the device, or the system kills your process, WorkManager persists the task to a local database and retries it when conditions allow. This is fundamentally different from a background service that disappears if the app is killed.

Deferrable means you don't control exactly when the work runs. You define constraints and WorkManager waits until those constraints are satisfied. Constraints can include requiring network connectivity, requiring the device to be charging, or requiring the battery to not be low. WorkManager picks the optimal time within those constraints.

Periodic tasks have a minimum interval of 15 minutes. This is enforced by the platform, not WorkManager. Android doesn't allow apps to schedule work more frequently than this to prevent battery abuse.

Under the hood, WorkManager uses JobScheduler on modern Android. It manages the complexity of backward compatibility and constraint handling for you.

WorkManager is the right choice for: syncing data with a server, uploading logs or analytics, processing downloaded files, cleaning up old cache entries, generating thumbnails, or sending queued messages.

WorkManager is the wrong choice for anything that needs to run immediately, at an exact time, or continuously.

Doze Mode and App Standby

Doze Mode activates when the device is unplugged, stationary, and the screen has been off for an extended period. In Doze, Android suspends network access, defers WorkManager tasks, ignores wake locks, and defers alarms. The system enters this state to conserve battery when the device is clearly not being used.

The system exits Doze periodically for maintenance windows during which deferred work can run. These windows become less frequent the longer the device stays in Doze.

Only high-priority Firebase Cloud Messaging notifications can break through Doze. This is why server-triggered background refresh is so powerful: your server sends a high-priority FCM message, Android wakes the app even in Doze to process it.

App Standby Buckets categorize your app based on how recently and frequently the user has interacted with it. The buckets are Active, Working Set, Frequent, Rare, and Restricted. The bucket your app is in directly affects how much background work it is allowed to do.

Active means the user used your app very recently. Full background execution allowed.

Working Set means the user uses your app regularly. Slight restrictions on how frequently background work can run.

Frequent means the user uses your app often but not daily. More restrictions.

Rare means the user barely uses your app. Significant restrictions. WorkManager tasks get delayed substantially.

Restricted means the app has been flagged for bad behavior or is almost never used. Background work is heavily throttled. The user or the system has effectively put your app on notice.

If your app ends up in the Rare or Restricted bucket, background sync becomes unreliable. The way to avoid this is straightforward: build an app people actually use regularly.

Flutter Implementation

Now let's look at how Flutter engineers implement background work using the native mechanisms above.

Setup: Project Structure

Background work in Flutter requires coordination between your Dart code and the native platform. The packages handle most of this, but there are configuration steps on both the iOS and Android sides that you must complete for the work to actually run.

workmanager

The workmanager package is the most widely used solution for deferrable background tasks in Flutter. It wraps Android WorkManager and iOS BGTaskScheduler.

Add the dependency:

dependencies:
  workmanager: ^0.5.2

On Android, no additional configuration is needed beyond the dependency. WorkManager is part of AndroidX and is available on all modern Android devices.

On iOS, add your task identifiers to Info.plist:

<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
  <string>com.yourapp.syncTask</string>
  <string>com.yourapp.cleanupTask</string>
</array>

Also add Background Modes capability in Xcode and enable Background fetch and Background processing.

The background callback must be a top-level function. It can't be inside a class:

@pragma('vm:entry-point')
void callbackDispatcher() {
  Workmanager().executeTask((taskName, inputData) async {
    switch (taskName) {
      case 'syncUserData':
        await syncUserData(inputData);
        break;
      case 'cleanupOldFiles':
        await cleanupOldFiles();
        break;
      default:
        print('Unknown task: $taskName');
    }
    return Future.value(true);
  });
}

The @pragma('vm:entry-point') annotation is critical. Without it, the Dart tree shaker may remove this function during release builds because it appears to be uncalled from Dart code. The platform calls it by name, not through Dart, so the tree shaker can't detect the reference.

Returning true from the task tells WorkManager the task succeeded. Returning false tells it the task failed and should be retried.

Initialize workmanager in your main function:

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  await Workmanager().initialize(
    callbackDispatcher,
    isInDebugMode: kDebugMode,
  );

  runApp(const MyApp());
}

isInDebugMode: true logs detailed information about task scheduling and execution. Turn this off in production.

Registering a one-time task:

Future<void> scheduleDataSync() async {
  await Workmanager().registerOneOffTask(
    'syncUserData',
    'syncUserData',
    initialDelay: const Duration(minutes: 5),
    constraints: Constraints(
      networkType: NetworkType.connected,
      requiresBatteryNotLow: true,
    ),
    inputData: {
      'userId': currentUser.id,
      'syncType': 'full',
    },
  );
}

The task will run once, after a minimum 5-minute delay, only when the device has network connectivity and the battery isn't low. The inputData map is passed to the callback and available as the inputData parameter in executeTask.

Registering a periodic task:

Future<void> schedulePeriodicSync() async {
  await Workmanager().registerPeriodicTask(
    'periodicSync',
    'syncUserData',
    frequency: const Duration(hours: 1),
    constraints: Constraints(
      networkType: NetworkType.connected,
    ),
  );
}

The minimum frequency is 15 minutes enforced by the platform. If you set a shorter interval, it gets rounded up to 15 minutes. On iOS, BGTaskScheduler controls the actual timing and may run the task less frequently based on device conditions.

Cancelling tasks:

// cancel one specific task
await Workmanager().cancelByUniqueName('periodicSync');

// cancel all registered tasks
await Workmanager().cancelAll();

flutter_background_service

The workmanager package is great for deferrable work, but sometimes you need something that runs continuously, like a health monitor, a real-time data collector, or a persistent connection.

For that, flutter_background_service creates a long-running service. On Android, this becomes a Foreground Service with a persistent notification. On iOS, it uses a combination of background modes.

Add the dependency:

dependencies:
  flutter_background_service: ^5.0.5
  flutter_local_notifications: ^17.0.0

The background service entry point, again, must be a top-level function:

@pragma('vm:entry-point')
void onStart(ServiceInstance service) async {
  DartPluginRegistrant.ensureInitialized();

  if (service is AndroidServiceInstance) {
    service.on('setAsForeground').listen((event) {
      service.setAsForegroundService();
    });

    service.on('setAsBackground').listen((event) {
      service.setAsBackgroundService();
    });
  }

  service.on('stopService').listen((event) {
    service.stopSelf();
  });

  // your actual background work runs here
  Timer.periodic(const Duration(seconds: 30), (timer) async {
    if (service is AndroidServiceInstance) {
      if (await service.isForegroundService()) {
        service.setForegroundNotificationInfo(
          title: 'App is running',
          content: 'Last sync: ${DateTime.now()}',
        );
      }
    }

    // do the actual work
    await performBackgroundSync();

    // send data to the main isolate if needed
    service.invoke('update', {
      'lastSync': DateTime.now().toIso8601String(),
    });
  });
}

Initialize the service:

Future<void> initializeBackgroundService() async {
  final service = FlutterBackgroundService();

  const AndroidNotificationChannel channel = AndroidNotificationChannel(
    'background_service',
    'Background Service',
    description: 'This channel is used for the background service notification',
    importance: Importance.low,
  );

  final FlutterLocalNotificationsPlugin flutterLocalNotificationsPlugin =
      FlutterLocalNotificationsPlugin();

  await flutterLocalNotificationsPlugin
      .resolvePlatformSpecificImplementation<
          AndroidFlutterLocalNotificationsPlugin>()
      ?.createNotificationChannel(channel);

  await service.configure(
    androidConfiguration: AndroidConfiguration(
      onStart: onStart,
      autoStart: true,
      isForegroundMode: true,
      notificationChannelId: 'background_service',
      initialNotificationTitle: 'App Running',
      initialNotificationContent: 'Background sync active',
      foregroundServiceNotificationId: 888,
    ),
    iosConfiguration: IosConfiguration(
      autoStart: true,
      onForeground: onStart,
      onBackground: onIosBackground,
    ),
  );

  await service.startService();
}

Communicating between the background service and your UI:

// in your widget, listen for updates from the background service
class HomeScreen extends StatefulWidget {
  @override
  State<HomeScreen> createState() => _HomeScreenState();
}

class _HomeScreenState extends State<HomeScreen> {
  String lastSync = 'Never';

  @override
  void initState() {
    super.initState();
    FlutterBackgroundService().on('update').listen((event) {
      setState(() {
        lastSync = event?['lastSync'] ?? 'Unknown';
      });
    });
  }

  void stopService() {
    FlutterBackgroundService().invoke('stopService');
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: Column(
        children: [
          Text('Last sync: $lastSync'),
          ElevatedButton(
            onPressed: stopService,
            child: const Text('Stop Background Service'),
          ),
        ],
      ),
    );
  }
}

The invoke and on methods create a two-way communication channel between the background isolate and the main isolate. The background service invokes events with data. The UI listens for those events and updates accordingly.

background_fetch

For simpler periodic background work where workmanager's full constraint system is more than you need, background_fetch provides a cleaner API.

dependencies:
  background_fetch: ^1.2.1

void main() {
  runApp(const MyApp());
  BackgroundFetch.registerHeadlessTask(backgroundFetchHeadlessTask);
}

@pragma('vm:entry-point')
void backgroundFetchHeadlessTask(HeadlessTask task) async {
  String taskId = task.taskId;
  bool isTimeout = task.timeout;

  if (isTimeout) {
    BackgroundFetch.finish(taskId);
    return;
  }

  await performQuickSync();
  BackgroundFetch.finish(taskId);
}

Configure and start:

Future<void> configureBackgroundFetch() async {
  await BackgroundFetch.configure(
    BackgroundFetchConfig(
      minimumFetchInterval: 15,
      stopOnTerminate: false,
      enableHeadless: true,
      requiresBatteryNotLow: false,
      requiresCharging: false,
      requiresStorageNotLow: false,
      requiresDeviceIdle: false,
      requiredNetworkType: NetworkType.ANY,
    ),
    (taskId) async {
      await performQuickSync();
      BackgroundFetch.finish(taskId);
    },
    (taskId) async {
      // timeout handler
      BackgroundFetch.finish(taskId);
    },
  );
}

Calling BackgroundFetch.finish(taskId) is mandatory. On iOS, failing to call finish tells the platform your task did not complete correctly, which affects future scheduling. On Android, it signals WorkManager that the task is done.

Persisting Data Between Isolates

Since the background isolate and the main isolate don't share memory, data must be persisted to disk.

The most common approaches are shared_preferences for simple key-value data and a local database like sqflite or isar for structured data.

// writing from background isolate
@pragma('vm:entry-point')
void callbackDispatcher() {
  Workmanager().executeTask((taskName, inputData) async {
    final prefs = await SharedPreferences.getInstance();

    // fetch new data
    final newData = await fetchFromServer();

    // persist for main isolate to read
    await prefs.setString('lastSyncData', jsonEncode(newData));
    await prefs.setString('lastSyncTime', DateTime.now().toIso8601String());

    return Future.value(true);
  });
}

// reading in main isolate when app comes to foreground
class HomeScreen extends StatefulWidget {
  @override
  State<HomeScreen> createState() => _HomeScreenState();
}

class _HomeScreenState extends State<HomeScreen> {
  @override
  void initState() {
    super.initState();
    loadLastSyncedData();
  }

  Future<void> loadLastSyncedData() async {
    final prefs = await SharedPreferences.getInstance();
    final data = prefs.getString('lastSyncData');
    final syncTime = prefs.getString('lastSyncTime');

    if (data != null) {
      setState(() {
        // update your state with the synced data
      });
    }
  }
}

The Decision Framework

Given a background task requirement, here is how to decide which approach to reach for:

Does the user expect something to actively be running, like music playing, navigation running, or a file uploading? Use a Foreground Service via flutter_background_service. The persistent notification isn't just a requirement, it's straightforward communication to the user about what the app is doing.

Does the work need to happen eventually but not necessarily right now? Something like syncing data, uploading logs, processing files, or cleaning the cache. If so, use workmanager. It guarantees the work runs, respects constraints, and survives app restarts and device reboots.

Does the work need to happen on a server-triggered signal? Use Firebase Cloud Messaging with a high-priority silent notification. Your server sends the signal, iOS and Android wake your app, your background isolate handles the work. This breaks through Doze Mode on Android and works with iOS's silent push mechanism.

Does the work need to happen on a simple periodic schedule with minimal constraints? Use background_fetch for a simpler API when workmanager's full constraint system is more than you need.

Does the work need precise timing? Rethink whether it truly needs to happen in the background. If a user sets a reminder for 3pm, a local notification is the right approach. The notification fires at the exact time regardless of whether the app is in the background.

One note about iOS specifically: no Flutter package can work around Apple's restrictions. If you register a BGAppRefreshTask, iOS decides when it runs. If you set constraints on WorkManager, Android decides when they're satisfied. The platform is in control. Your job is to declare what you need clearly, handle it correctly when the platform gives you the window, and build your app to be resilient when the background work runs later than expected.

Conclusion

Background execution on mobile isn't a Flutter problem or a Dart problem. It's a platform problem that Flutter sits on top of.

iOS is restrictive by design. You declare the specific category of background work you need. Apple evaluates whether that use case is legitimate. When granted, the platform gives you controlled, time-limited windows. Exceed those windows and the system terminates your task.

Android started permissive and has been getting stricter with every major version. Foreground Services give reliable continuous execution with a visible notification. WorkManager gives guaranteed deferred execution with constraints. Doze Mode and App Standby Buckets restrict everything else based on device state and user behavior.

Flutter bridges both through packages that map to the native APIs. workmanager covers deferrable work on both platforms. flutter_background_service covers continuous work with a foreground notification. background_fetch covers simple periodic work with a cleaner API.

The engineers who succeed with mobile background work are the ones who understand what the platform is actually doing and design with those constraints in mind. They don't fight the platform. They declare what they need, handle the windows they're given, persist state properly across isolate boundaries, and build their systems to be resilient when background work is delayed or deferred.

That's how background work actually gets done on mobile.

Understanding the core of background processes and app lifecycle in native and hybrid mobile engineering helps you make an informed architectural decision when selecting the task handler needed to run a specific task.

Happy Coding!!

You have a set of objects: different types, shapes, and data. And at some point, someone asks you to perform an operation on all of them, like exporting them them to PDF, sending them a notification, generating a report, or calculating their fees.

Your first instinct might be to write a function that checks the type and branches accordingly, like an if-else block or switch statement. Something that says: if this is a NewUser, do this. If this is a JointAccountUser, do that. It works, you ship it, and everyone is happy.

Then another operation comes in. And another. Every single time, you go back to the same place and add another branch. The function grows. The class grows. The test surface grows. What started as a clean model is now a god object that knows how to do everything for everyone.

The Visitor Design Pattern exists to break this cycle completely.

Table of Contents

• What is the Visitor Design Pattern?

• The Problem the Visitor Pattern Solves

• Core Components

• Real World Example One: Document Export

• Real World Example Two: Notification System

• Real World Example Three: Fee Calculation

• The Power of Combining All Three Operations

• When to Use the Visitor Pattern

• When Not to Use It

• Conclusion

What is the Visitor Design Pattern?

The Visitor pattern is a behavioral design pattern that lets you define a new operation on a family of objects without changing the objects themselves.

The key word there is behavioral. Behavioral patterns are about how objects communicate and distribute responsibility. Where creational patterns deal with how objects are created and structural patterns deal with how they are composed, behavioral patterns deal with how they interact and who is responsible for what.

The Visitor pattern specifically deals with the question of who should own an operation when that operation needs to work differently across multiple object types.

The classic answer is: put the operation on each object. Give each class a method that handles the operation for its own type. But this breaks down the moment you have multiple operations, because now every new operation means touching every class. You're spreading one concern across your entire object hierarchy.

The Visitor pattern flips this. Instead of spreading the operation across the objects, you collect it into one place called a Visitor. The objects simply accept the visitor and let it do its work. Adding a new operation means creating a new Visitor. The existing objects don't change at all.

This is the Open/Closed Principle working exactly as intended: open for extension, closed for modification.

The Problem the Visitor Pattern Solves

Let me show you exactly what this looks like without the Visitor pattern.

Say you have a fintech platform with four types of users: existing customers, new customers, minor account holders, and joint account holders. Your product manager comes in and asks you to add document export. Every user type should be exportable to PDF, Excel, and CSV.

Without Visitor, the natural approach looks something like this:

class ExistingUser {
  final int id;
  final String firstName;
  final String lastName;
  final DateTime lastPaymentDate;
  final num accountBalance;

  String exportToPdf() {
    return '$firstName\n$lastName\n$lastPaymentDate\n$accountBalance';
  }

  String exportToExcel() {
    return '$firstName,$lastName,$lastPaymentDate,$accountBalance';
  }

  String exportToCsv() {
    return '"$firstName","$lastName","$lastPaymentDate","$accountBalance"';
  }
}

And you repeat this for NewUser, MinorAccountUser, and JointAccountUser. Twelve methods spread across four classes just for document export.

Now the product manager comes back. They want notifications: email, SMS, and Push. Back you go to all four classes, adding three more methods each. Twelve more methods spread across the same four classes.

Then they want fee calculation. Then they want KYC status checks. Every new operation multiplies across every user type. The classes grow, the reasons to change multiply, and testing becomes painful.

This is the exact problem the Visitor pattern was built to solve.

Core Components

The Visitor pattern has four core components. Understanding each one before looking at code makes the implementation much easier to follow.

The Visitor Interface

This is the contract that every visitor must implement. It declares one method per object type it needs to visit. A visitor that handles four user types declares four visit methods, one for each type.

The Concrete Visitors

These are the real implementations of the Visitor interface. Each one represents a single operation and knows how to handle every object type. A PdfHandler is a concrete visitor. An ExcelHandler is a concrete visitor. A SmsNotificationHandler is a concrete visitor. Each one has one job and knows how to do that job for every user type.

The Consumer Interface (also called Element or Acceptor)

This is the contract that every object in the hierarchy must implement. It declares a single accept method that takes a Visitor and calls the right visit method on it. This is the double dispatch mechanism that makes the pattern work.

The Concrete Consumers

These are the real objects in the hierarchy: ExistingCustomers, NewCustomers, MinorCustomer, and JointCustomer. Each one implements accept by calling the specific visit method that corresponds to its own type.

Think of it this way. The Visitor interface is implemented by every operation you want to perform: PdfHandler, ExcelHandler, and CsvHandler. Each of these knows how to handle all four user types.

The Consumer interface is implemented by every object in the hierarchy: ExistingCustomers, NewCustomers, MinorCustomer, and JointCustomer. Each of these knows how to receive a visitor and route it to the correct method.

When you call existingCustomer.accept(pdfHandler), ExistingCustomers calls pdfHandler.visitExistingCustomer(this) and passes itself as the argument. The right method fires automatically. There's no type checking, if-else, or switch. The object tells the visitor who it is, and the visitor knows exactly what to do with that information.

Real World Example One: Document Export

This is a real scenario from a fintech platform. There are four user types with different data structures, all needing to export their information to three document formats: PDF, Excel, and CSV.

Step 1: Define the User Models

class ExistingUser {
  final int id;
  final String firstName;
  final String lastName;
  final DateTime lastPaymentDate;
  final num accountBalance;

  const ExistingUser({
    required this.id,
    required this.firstName,
    required this.lastName,
    required this.lastPaymentDate,
    required this.accountBalance,
  });
}

class NewUser {
  final String firstName;
  final String lastName;

  const NewUser({
    required this.firstName,
    required this.lastName,
  });
}

class MinorAccountUser {
  final int age;
  final int guardianId;
  final String firstName;
  final String lastName;
  final String guardianName;

  const MinorAccountUser({
    required this.age,
    required this.guardianId,
    required this.firstName,
    required this.lastName,
    required this.guardianName,
  });
}

class JointAccountUser {
  final int jointAccountId;
  final List<String> accountHoldersInfo;
  final num accountBalance;

  const JointAccountUser({
    required this.jointAccountId,
    required this.accountHoldersInfo,
    required this.accountBalance,
  });
}

We have four models. Each one owns its own data and nothing else. There's no export logic or notification logic. And no business operations of any kind. Just clean data structures.

This is exactly how it should be. The model's job is to hold data. The visitor's job is to operate on it.

Step 2: Define the Visitor and Consumer Interfaces

abstract class UserVisitor<T> {
  T visitExistingCustomer(ExistingUser user);
  T visitNewCustomer(NewUser user);
  T visitMinorCustomer(MinorAccountUser user);
  T visitJointCustomer(JointAccountUser user);
}

abstract class UserConsumer {
  T accept<T>(UserVisitor<T> visitor);
}

UserVisitor<T> is generic. The type parameter T represents what the visitor returns. A document export visitor returns a String. A fee calculation visitor might return a double. A validation visitor might return a bool. The same pattern works for any return type.

UserConsumer declares the accept method. Every object in the hierarchy must implement this. The accept method is what makes the double dispatch work. The object receives the visitor and immediately calls the right visit method on it, passing itself as the argument.

Step 3: Implement the Concrete Consumers

class ExistingCustomers implements UserConsumer {
  final ExistingUser user;
  ExistingCustomers({required this.user});

  @override
  T accept<T>(UserVisitor<T> visitor) {
    return visitor.visitExistingCustomer(user);
  }
}

class NewCustomers implements UserConsumer {
  final NewUser user;
  NewCustomers({required this.user});

  @override
  T accept<T>(UserVisitor<T> visitor) {
    return visitor.visitNewCustomer(user);
  }
}

class MinorCustomer implements UserConsumer {
  final MinorAccountUser user;
  MinorCustomer({required this.user});

  @override
  T accept<T>(UserVisitor<T> visitor) {
    return visitor.visitMinorCustomer(user);
  }
}

class JointCustomer implements UserConsumer {
  final JointAccountUser user;
  JointCustomer({required this.user});

  @override
  T accept<T>(UserVisitor<T> visitor) {
    return visitor.visitJointCustomer(user);
  }
}

Each consumer wraps one user model and implements accept by forwarding to the correct visit method. This is the entire job of a concrete consumer. It knows who it is, and it tells the visitor by calling the right method.

Notice that none of these classes know anything about PDF, Excel, CSV, email, SMS, or any operation. They're completely decoupled from every operation that will ever be performed on them.

Step 4: Implement the Concrete Visitors

class PdfHandler implements UserVisitor<String> {
  @override
  String visitExistingCustomer(ExistingUser user) {
    return '${user.firstName} ${user.lastName}'
        '\nBalance: ${user.accountBalance}'
        '\nLast Payment: ${user.lastPaymentDate}';
  }

  @override
  String visitNewCustomer(NewUser user) {
    return '${user.firstName} ${user.lastName}';
  }

  @override
  String visitMinorCustomer(MinorAccountUser user) {
    return '${user.firstName} ${user.lastName}'
        '\nAge: ${user.age}'
        '\nGuardian: ${user.guardianName} (ID: ${user.guardianId})';
  }

  @override
  String visitJointCustomer(JointAccountUser user) {
    final holders = user.accountHoldersInfo.join(', ');
    return 'Joint Account ID: ${user.jointAccountId}'
        '\nHolders: $holders'
        '\nBalance: ${user.accountBalance}';
  }
}

class ExcelHandler implements UserVisitor<String> {
  @override
  String visitExistingCustomer(ExistingUser user) {
    return '${user.firstName}\t${user.lastName}'
        '\t${user.accountBalance}\t${user.lastPaymentDate}';
  }

  @override
  String visitNewCustomer(NewUser user) {
    return '${user.firstName}\t${user.lastName}';
  }

  @override
  String visitMinorCustomer(MinorAccountUser user) {
    return '${user.firstName}\t${user.lastName}'
        '\t${user.age}\t${user.guardianName}\t${user.guardianId}';
  }

  @override
  String visitJointCustomer(JointAccountUser user) {
    final holders = user.accountHoldersInfo.join('\t');
    return '${user.jointAccountId}\t$holders\t${user.accountBalance}';
  }
}

class CsvHandler implements UserVisitor<String> {
  @override
  String visitExistingCustomer(ExistingUser user) {
    return '"${user.firstName}","${user.lastName}"'
        ',"${user.accountBalance}","${user.lastPaymentDate}"';
  }

  @override
  String visitNewCustomer(NewUser user) {
    return '"${user.firstName}","${user.lastName}"';
  }

  @override
  String visitMinorCustomer(MinorAccountUser user) {
    return '"${user.firstName}","${user.lastName}"'
        ',"${user.age}","${user.guardianName}","${user.guardianId}"';
  }

  @override
  String visitJointCustomer(JointAccountUser user) {
    final holders = user.accountHoldersInfo.map((h) => '"$h"').join(',');
    return '"${user.jointAccountId}",$holders,"${user.accountBalance}"';
  }
}

Each handler implements the visitor interface and knows exactly how to format each user type for its specific document format. PdfHandler uses newlines and labels. ExcelHandler uses tabs. CsvHandler wraps values in quotes and separates with commas.

The formatting logic for each document type lives in exactly one class. If the PDF format changes, you touch only PdfHandler. If the CSV format changes, you touch only CsvHandler. The user models never change.

Step 5: Use It

void existingUserLogic() {
  final customer = ExistingCustomers(
    user: ExistingUser(
      id: 10,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      lastPaymentDate: DateTime.now(),
      accountBalance: 7373773.39,
    ),
  );

  final pdf = customer.accept(PdfHandler());
  final excel = customer.accept(ExcelHandler());
  final csv = customer.accept(CsvHandler());

  print('PDF:\n$pdf\n');
  print('Excel:\n$excel\n');
  print('CSV:\n$csv\n');
}

void newUserLogic() {
  final customer = NewCustomers(
    user: NewUser(
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
    ),
  );

  customer.accept(PdfHandler());
  customer.accept(ExcelHandler());
  customer.accept(CsvHandler());
}

void minorUserLogic() {
  final customer = MinorCustomer(
    user: MinorAccountUser(
      age: 15,
      guardianId: 82882,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      guardianName: 'Inioluwa',
    ),
  );

  customer.accept(PdfHandler());
  customer.accept(ExcelHandler());
  customer.accept(CsvHandler());
}

void jointUserLogic() {
  final customer = JointCustomer(
    user: JointAccountUser(
      jointAccountId: 92,
      accountHoldersInfo: [
        'Oluwaseyi',
        'Aderonke',
        'Inioluwa',
        'Tiwaloluwa',
      ],
      accountBalance: 9200020202.22,
    ),
  );

  customer.accept(PdfHandler());
  customer.accept(ExcelHandler());
  customer.accept(CsvHandler());
}

The same customer object accepts any visitor with the same call. The type dispatch happens automatically through the accept method. There's no type checking anywhere in the calling code, and no if-else or switch. Just customer.accept(handler) and the right method fires.

Now think about what happens when you need to add an XML export. You create one new class, XmlHandler, implement the four visit methods, and that's it. You don't touch ExistingUser, NewUser, MinorAccountUser, JointAccountUser, or any of the existing handlers. The system is genuinely open for extension and closed for modification.

Real World Example Two: Notification System

Here we have the same four user types and the same pattern. But it's a different operation entirely.

Your platform needs to notify users about account events. But not every user type should be notified the same way.

Existing users get email and push notifications. New users only get email because they haven't fully set up their profile yet. Minor account users get SMS to their guardian's number. Joint account users get notified on all channels because multiple people share the account.

Without the Visitor pattern, this logic would spread across all four user models or collapse into one enormous function full of type checks. With Visitor, it lives in three focused classes.

The Notification Visitor Interface

abstract class NotificationVisitor {
  void visitExistingCustomer(ExistingUser user);
  void visitNewCustomer(NewUser user);
  void visitMinorCustomer(MinorAccountUser user);
  void visitJointCustomer(JointAccountUser user);
}

This visitor returns void because notifications are side effects. They send messages, they don't return values.

The Concrete Notification Visitors

class EmailNotificationHandler implements NotificationVisitor {
  @override
  void visitExistingCustomer(ExistingUser user) {
    print('Sending email to existing customer: ${user.firstName}');
    // email service call with full account details
  }

  @override
  void visitNewCustomer(NewUser user) {
    print('Sending welcome email to new customer: ${user.firstName}');
    // welcome email with onboarding steps
  }

  @override
  void visitMinorCustomer(MinorAccountUser user) {
    print('Sending email to guardian: ${user.guardianName}');
    // email goes to guardian, not the minor
  }

  @override
  void visitJointCustomer(JointAccountUser user) {
    for (final holder in user.accountHoldersInfo) {
      print('Sending email to joint holder: $holder');
      // all account holders get notified
    }
  }
}

class SmsNotificationHandler implements NotificationVisitor {
  @override
  void visitExistingCustomer(ExistingUser user) {
    print('Sending SMS to existing customer: ${user.firstName}');
  }

  @override
  void visitNewCustomer(NewUser user) {
    // new users are not SMS-verified yet, skip
    print('New customer ${user.firstName} not SMS-eligible yet');
  }

  @override
  void visitMinorCustomer(MinorAccountUser user) {
    print('Sending SMS to guardian ${user.guardianName} for minor ${user.firstName}');
    // SMS goes to guardian's registered number
  }

  @override
  void visitJointCustomer(JointAccountUser user) {
    for (final holder in user.accountHoldersInfo) {
      print('Sending SMS to joint holder: $holder');
    }
  }
}

class PushNotificationHandler implements NotificationVisitor {
  @override
  void visitExistingCustomer(ExistingUser user) {
    print('Push notification to existing customer: ${user.firstName}');
  }

  @override
  void visitNewCustomer(NewUser user) {
    print('Push notification to new customer: ${user.firstName}');
  }

  @override
  void visitMinorCustomer(MinorAccountUser user) {
    // minors do not have the app installed yet, guardian gets push
    print('Push notification to guardian: ${user.guardianName}');
  }

  @override
  void visitJointCustomer(JointAccountUser user) {
    for (final holder in user.accountHoldersInfo) {
      print('Push notification to joint holder: $holder');
    }
  }
}

Each handler knows the specific rules for each user type. SmsNotificationHandler knows that new users aren't SMS-verified yet. PushNotificationHandler knows that minor account notifications go to the guardian. EmailNotificationHandler knows that joint account holders all need to be notified individually.

This business logic lives in exactly one place per notification channel. When the rules change (and they always change), you update one class.

Using the Notification Visitors

void notifyExistingUser() {
  final customer = ExistingCustomers(
    user: ExistingUser(
      id: 10,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      lastPaymentDate: DateTime.now(),
      accountBalance: 7373773.39,
    ),
  );

  customer.accept(EmailNotificationHandler());
  customer.accept(SmsNotificationHandler());
  customer.accept(PushNotificationHandler());
}

void notifyMinorUser() {
  final customer = MinorCustomer(
    user: MinorAccountUser(
      age: 15,
      guardianId: 82882,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      guardianName: 'Inioluwa',
    ),
  );

  // all three channels fire, each with minor-specific rules
  customer.accept(EmailNotificationHandler());
  customer.accept(SmsNotificationHandler());
  customer.accept(PushNotificationHandler());
}

void notifyJointUser() {
  final customer = JointCustomer(
    user: JointAccountUser(
      jointAccountId: 92,
      accountHoldersInfo: [
        'Oluwaseyi',
        'Aderonke',
        'Inioluwa',
        'Tiwaloluwa',
      ],
      accountBalance: 9200020202.22,
    ),
  );

  customer.accept(EmailNotificationHandler());
  customer.accept(SmsNotificationHandler());
  customer.accept(PushNotificationHandler());
}

The calling code is identical regardless of the user type or the notification channel. The dispatch is automatic. The rules live inside the visitors.

When WhatsApp notifications become a requirement (and they will), you create one WhatsAppNotificationHandler class with four visit methods. Nothing else changes.

Real World Example Three: Fee Calculation

Again, we have the same four user types and the same pattern. And once again, we have a completely different operation.

Your platform needs to calculate monthly maintenance fees. But each user type has different rules.

Existing customers pay a flat monthly fee based on their account balance. New customers are fee-exempt for their first three months. Minor account holders pay a reduced fee because their accounts have restricted features. Joint account holders have their fee split equally across all account holders.

Without Visitor, this logic ends up as a giant method somewhere with four branches, or worse, it leaks into the user models themselves. With Visitor, it lives in one focused class.

The Fee Visitor Interface

abstract class FeeVisitor {
  double visitExistingCustomer(ExistingUser user);
  double visitNewCustomer(NewUser user);
  double visitMinorCustomer(MinorAccountUser user);
  double visitJointCustomer(JointAccountUser user);
}

This visitor returns a double because fee calculation produces a numeric value.

The Concrete Fee Visitor

class MonthlyFeeCalculator implements FeeVisitor {
  @override
  double visitExistingCustomer(ExistingUser user) {
    // 0.5% of account balance, minimum 500, maximum 5000
    final fee = user.accountBalance * 0.005;
    return fee.clamp(500, 5000).toDouble();
  }

  @override
  double visitNewCustomer(NewUser user) {
    // new customers are fee-exempt for the first 3 months
    return 0.0;
  }

  @override
  double visitMinorCustomer(MinorAccountUser user) {
    // flat reduced fee for minor accounts
    return 150.0;
  }

  @override
  double visitJointCustomer(JointAccountUser user) {
    // standard fee split equally across all holders
    const standardFee = 2000.0;
    return standardFee / user.accountHoldersInfo.length;
  }
}

Every fee rule for every user type lives in this one class. When the fee structure changes for existing customers, you touch one method in one class. When minor account fees are updated, same thing. None of the user models change, and no other visitor changes.

Using the Fee Visitor

void calculateFees() {
  final existingCustomer = ExistingCustomers(
    user: ExistingUser(
      id: 10,
      firstName: 'Oluwaseyi',
      lastName: 'Fatunmole',
      lastPaymentDate: DateTime.now(),
      accountBalance: 7373773.39,
    ),
  );

  final newCustomer = NewCustomers(
    user: NewUser(
      firstName: 'Aderonke',
      lastName: 'Fatunmole',
    ),
  );

  final minorCustomer = MinorCustomer(
    user: MinorAccountUser(
      age: 15,
      guardianId: 82882,
      firstName: 'Inioluwa',
      lastName: 'Fatunmole',
      guardianName: 'Oluwaseyi',
    ),
  );

  final jointCustomer = JointCustomer(
    user: JointAccountUser(
      jointAccountId: 92,
      accountHoldersInfo: [
        'Oluwaseyi',
        'Aderonke',
        'Inioluwa',
        'Tiwaloluwa',
      ],
      accountBalance: 9200020202.22,
    ),
  );

  final calculator = MonthlyFeeCalculator();

  final existingFee = existingCustomer.accept(calculator);
  final newFee = newCustomer.accept(calculator);
  final minorFee = minorCustomer.accept(calculator);
  final jointFee = jointCustomer.accept(calculator);

  print('Existing customer fee: NGN $existingFee');
  print('New customer fee: NGN $newFee');
  print('Minor account fee: NGN $minorFee');
  print('Joint account fee per holder: NGN $jointFee');
}

The output:

Existing customer fee: NGN 5000.0
New customer fee: NGN 0.0
Minor account fee: NGN 150.0
Joint account fee per holder: NGN 500.0

When a PremiumFeeCalculator is needed for a new tier of customers, you create one new class that implements FeeVisitor. The user models stay exactly as they are. The MonthlyFeeCalculator stays exactly as it is. The accept methods on all four consumers stay exactly as they are.

The Power of Combining All Three Operations

Here's what makes the Visitor pattern truly shine in a system like this. You have the same four user types, and you can run any combination of visitors on any of them in the same call chain.

void processUser(UserConsumer customer) {
  final pdf = customer.accept(PdfHandler());
  final csv = customer.accept(CsvHandler());

  customer.accept(EmailNotificationHandler());
  customer.accept(PushNotificationHandler());

  final fee = customer.accept(MonthlyFeeCalculator());

  print('Fee: NGN $fee');
  print('Documents generated and notifications sent');
}

One function, any user type, any combination of operations. The consumer doesn't care which visitors it receives. The visitors don't care which consumers call them. They speak to each other through the interface, and the interface guarantees everything works correctly.

We have three completely different operations (document export, notifications, and fee calculation) all applied to the same object with the same call pattern. None of these operations know about each other. None of them touch the user models. Each one lives in its own focused class with its own single reason to change.

When to Use the Visitor Pattern

Use Visitor when you have a stable set of object types and a growing set of operations on them.

The pattern shines when the object hierarchy is unlikely to change frequently. It's optimized for adding new operations, not new types. Adding a new user type means updating every existing visitor. If your object types change constantly, Visitor creates more work than it saves.

It's also very effective when you need to perform multiple unrelated operations on a family of objects without polluting their classes with that logic. Document export, notification handling, fee calculation, and KYC validation are all unrelated operations. Each belongs in its own visitor, not scattered across the user models.

Visitor also works well when you want clean separation between data and behavior. The models hold data and the visitors define behavior. This makes both easier to understand, easier to test, and easier to maintain independently.

When Not to Use It

Avoid Visitor when the object hierarchy changes frequently. Every time you add a new type, you must update every existing visitor. In a system where new user types appear regularly, this becomes painful quickly.

It's also not helpful when you only have one or two operations. For simple cases, the overhead of creating visitor interfaces, consumer interfaces, and multiple classes is not worth the benefit.

And avoid it when the operations are tightly coupled to the object's internal state in ways that make sense to keep together. Some behavior naturally belongs on the object itself.

Conclusion

The Visitor Design Pattern solves a problem that most developers only recognize after they've already made a mess of it. You have a family of objects with different types and different data. Operations come in one after another. Without a deliberate structure, those operations spread everywhere: into the models, utility classes, and massive switch statements that nobody wants to touch.

Visitor collects each operation into one focused class. The models stay clean and the operations stay isolated. Adding a new operation means creating one new class. The existing code doesn't change.

In the fintech examples above, we have three entirely different concerns: document export, notifications, and fee calculation. All are handled by handled by focused classes, none of which know anything about each other. The user models don't know about PDF or email or fees. The PdfHandler doesn't know about SMS. The MonthlyFeeCalculator doesn't know about push notifications. Each class has exactly one reason to exist and exactly one reason to change.

That s what a well-applied Visitor pattern looks like in practice. Clean, focused, and genuinely extensible.

Happy coding!

Apps are hungry for your data. Hackers are always looking for cracks in your security. And sometimes, we accidentally give away more than we realize.

The good news is you don’t need to be an expert to tighten things up.

Here are seven simple changes that can seriously improve your phone’s privacy. Each one takes just a few minutes, and together, they make your phone much harder to track, hack, or snoop on.

Control What Tracks Your Location

Let’s start with location tracking.

Most people don’t realize how many apps can access their exact whereabouts. Even seemingly harmless apps like weather or games may collect this info in the background.

Some use it to target ads, others sell it to data brokers, and a few could open doors to more serious threats, like someone building a full profile of your movements.

To reduce the risk, go into your phone’s settings and check which apps can access your location. Both iPhone and Android let you limit access to “While Using” the app, instead of “Always.” This way, apps can’t track you silently in the background.

Also, turn off “Precise Location” for apps that don’t need it. Your phone will still know your city, but it won’t pinpoint your exact house. This one tweak keeps dozens of apps from silently tracking your every move.

Make Your Passcode Stronger

Next up is your passcode. It’s your phone’s first line of defense, but far too many people still use weak ones  –  like birthdays, 123456, or just swiping a simple pattern.

If someone grabs your phone, a weak passcode makes it much easier for them to get in, especially if they’ve watched you unlock it a few times.

Switch to at least a six-digit PIN or, even better, an alphanumeric passcode with letters and numbers. Yes, it takes a second longer to type, but it’s far harder to guess.

And if your phone supports it, use your fingerprint for unlocking instead of facial recognition. Face unlock can sometimes be fooled by photos or similar faces, while fingerprints are generally more secure.

You should also consider enabling a setting that erases your data after multiple failed login attempts. This way, if your phone falls into the wrong hands, it won’t just be sitting there, waiting to be cracked.

Cut Back Unnecessary App Permissions

Many apps ask for permissions they don’t really need.

A flashlight app that wants access to your contacts? A calendar app asking for microphone access? These are red flags.

The more permissions you grant, the more ways your data can leak  –  sometimes to advertisers, other times to third parties you’ve never heard of.

Go through your app permissions and turn off access that doesn’t make sense. Does that casual game really need your location? Does a recipe app need to see your photos? Probably not. This isn’t just about avoiding creepy behavior  –  it’s about reducing the number of ways bad actors can exploit your phone if something goes wrong.

Some malicious apps have been caught using these permissions to record audio, access files, or even track your activity across other apps. A regular permissions check-up can help stop that from happening.

Switch to eSIM for Better Security

One of the most overlooked privacy upgrades is switching to an eSIM card. That’s a digital SIM card built into your phone, and it offers real advantages over traditional physical SIM cards. The biggest one is security.

Physical SIM cards can be switched out easily if someone steals your phone. There’s also the risk of SIM swapping  –  where attackers convince your carrier to transfer your number to a different SIM, giving them control of your calls, texts, and even two-factor authentication codes.

With an eSIM, there’s no physical card to remove, and activating or transferring it requires extra authentication through your carrier.

If your phone supports eSIM – and most modern iPhones, Pixels, and Galaxy devices do –  you can switch by contacting your mobile carrier or using their app.

Once your eSIM is set up, consider removing the physical SIM entirely. It’s one less way someone can try to hijack your phone number.

Don’t Leave Bluetooth and Wi‑Fi Open

You might not think twice about leaving Bluetooth or Wi-Fi turned on, but doing so can leave your phone exposed.

Even when you’re not actively connected, your phone continues to look for known networks or nearby devices. This “sniffing” can give away your location, expose your device to tracking, or even let attackers try to exploit unpatched vulnerabilities.

For instance, there have been real-world attacks like BlueBorne, which let hackers take over phones just by being nearby with Bluetooth turned on.

Another risk is “Wi-Fi spoofing” –  when someone sets up a fake public network to trick your phone into connecting, giving them access to your traffic.

To protect yourself, get into the habit of turning off Wi-Fi and Bluetooth when you’re not using them. You’ll save battery, too.

If you’re connecting to public networks, avoid auto-connect settings and tell your phone to “forget” the network afterward. This keeps it from reconnecting without your knowledge later.

Use Encrypted Messaging Apps

Plain old text messages are easy to intercept. Phone carriers can access them, and if someone manages to snoop on your network, they can read your texts without much effort. That’s why encrypted messaging apps matter.

Signal is one of the best options out there. It uses end-to-end encryption, which means only you and the person you’re chatting with can read your messages. Not even the app company can see them. It’s also open-source, which means experts can inspect the code for flaws.

WhatsApp also uses strong encryption, but it’s owned by Meta (formerly Facebook), which has a spottier track record when it comes to data privacy.

If you’re serious about protecting private conversations  –  especially with family, coworkers, or anyone handling sensitive info  – make the switch to an encrypted app.

Keep Your Software Updated

The last one is simple, but often ignored: keep your phone and apps updated. Every update includes security patches that fix known issues.

Hackers and malware often target devices running old software because those bugs are public knowledge by the time they strike. If your phone isn’t set to update automatically, change that now.

Also check your app updates regularly. Some apps introduce new permissions or bugs, so keeping everything current helps close those holes before they can be used against you.

Phones with outdated operating systems are more vulnerable to spyware, data theft, and unauthorized access. So even if you’re not excited about the new features, updates are your silent protectors behind the scenes.

Conclusion

None of these steps will make you invisible –  but they will make your phone a lot harder to compromise. That’s the goal. Privacy isn’t about locking everything down forever. It’s about knowing what you’re sharing, and taking steps to control it.

Hope you enjoyed this article. You can learn more about me or connect with me on Linkedidn.

The mobile development team just pushed a big update with many helpful improvements, including the much-awaited /learn user experience.

You can now code your way through the Responsive Web Design curriculum and save your progress – right on your phone. You can seamlessly shift your freeCodeCamp learning from your desktop to your phone at any time.

And we're working on implementing even more certifications, including our JavaScript Algorithms and Data Structures certification.

The /learn experience features a built-in code editor specifically designed for easy coding on the go. You can also use it to build your certification projects.

Here's a sneak peek into the /learn experience on a mobile device:

A view of the instructions pane telling the user how to complete the challenge

It's also possible to preview your challenges and projects. This shows a preview of the Camper Café project:

Of course, there are so many more tutorials and features to explore in the mobile app. But we'll leave those for you to discover. 😉

We've also made some improvements to /news, Code Radio, and our Podcast listener – which are also available in the app.

How can I download the app?

You can visit the Play Store page and download the official freeCodeCamp app.

If you are not able to access the Google Play Store in your country, you can download the latest version of the .apk file directly from GitHub.

Many of the reviews of the app are of the old 2021 version, which was just a simple web app version that had lots of bugs.

This new version is the result of thousands of hours of development by the freeCodeCamp engineering team. We are very proud of this powerful Flutter-based Android app.

So after you use it for a while, if you like it and find it to be helpful, be sure to leave a 5-star review. 😉

How can I help the freeCodeCamp community beta test upcoming features?

Here's how to sign up for the open beta on Android. (We're working on getting the iOS version live soon, too.)

First, visit the Google Play Store page.

At the bottom of the page, there should be a message saying "Join the beta." Just click join, and the app page should show you an update button shortly afterward.

That's it – you are now officially in the beta program. 🧑‍💻

You may see this message in the Google Play Store.

Do note that your progress will not yet be saved on freeCodeCamp's servers. It will only be stored locally on your device. This means that any progress you make will not count towards completing any projects on the freeCodeCamp website. But we're working hard to add this functionality ASAP.

Thank you to all the open source contributors who have helped develop the freeCodeCamp mobile app so far. We are just getting started.

If you are interested in contributing to the mobile app, you can learn a lot about Flutter development and User Experience while helping the community. I encourage you to start your contribution journey with this guide.

Happy coding. 🙂

What if you could monitor your Colab, Kaggle, or AzureML Machine Learning projects on your mobile phone? You'd be able to check in on your models on the fly – even while taking a walk🚶.

If you are an ML developer, you know how training models can easily take a long time. How cool would it be to monitor this from your mobile phones?

Well, you can do it – and in <5 lines of code.

Why Monitoring Your Models Remotely Helps

Before getting on with the tutorial and showing you how it works, let me briefly describe what you can do with TF Watcher, an open-source project we will use to monitor our ML jobs:

• Integrates seamlessly with your ML workflow, so you don't need to change any other code in your workflow to make it work
• All your visualizations and dashboards are real-time
• You probably want to share your live dashboard or a previously run dashboard with your colleagues, and this also allows you to create shareable links
• It's a PWA which lets you monitor your models offline in a limited capacity
• You also get precise control over when you want to log the metrics

How to Monitor Your ML Projects on Your Phone

Let's now go through the tutorial of how to monitor your models on a mobile device with Google Colab. I'll show you how to use tool this in Google Colab, so anyone can try it out, but you can pretty much replicate this anywhere (even on your local machine).

Feel free to follow along with this colab notebook.

Install the tf-watcher Python Package

To monitor your Machine Learning jobs on mobile devices, you need to install the tf-watcher Python package. This is an open-source Python package that I built, and you can find the source code in this GitHub repo.

To install the Python package from PyPI, run the following command in your notebook cell:

 !pip install tf-watcher

How to Create a Simple Model

For the purposes of this example, we will see how you can monitor a training job – but you can use this package to monitor your evaluation or prediction jobs too. You will soon also see how you can easily specify the metrics you want to monitor.

In this example, we’ll use the Fashion MNIST, a simple dataset of 60,000 grayscale images of 10 fashion categories. We start by loading the dataset and then we'll do some simple preprocessing to further speed up our example.

However, you can use everything we talk about in this article in your more complex experiments.

Let's fetch the dataset:

import tensorflow as tf

# Load example MNIST data and pre-process it
(x_train, y_train), (x_test, y_test) = tf.keras.datasets.mnist.load_data()

x_train = x_train.reshape(-1, 784).astype("float32") / 255.0
x_test = x_test.reshape(-1, 784).astype("float32") / 255.0

# Limit the data to 1000 samples to make it faster
x_train = x_train[:1000]
y_train = y_train[:1000]
x_test = x_test[:1000]
y_test = y_test[:1000]

Now we'll create a simple neural network that just has a single Dense layer. I'll be showing you how to use this with the TensorFlow's Sequential API, but this works in the exact same way while using the Functional API or subclassed models, too.

# Define the Keras model
def get_model():
    model = keras.Sequential()
    model.add(keras.layers.Dense(1, input_dim=784))
    model.compile(
        optimizer=keras.optimizers.RMSprop(learning_rate=0.1),
        loss="mean_squared_error",
        metrics=["accuracy"],
    )
    return model

You might have noticed that while compiling our model, we also specified metrics which lets us specify which metrics we need to monitor.

Here I mention "accuracy" so I should be able to monitor accuracy on my mobile device. By default, we logged "loss" so in this case, we would be monitoring 2 metrics: loss and accuracy.

You can add as many metrics as you need. You can also use TensorFlow's built-in metrics or add your own custom metric, too.

How to Create an Instance of a Callback Class

You will now import TF Watcher and create an instance of one of its classes:

import tfwatcher

MonitorCallback = tfwatcher.callbacks.EpochEnd(schedule = 1)

In this example:

• We use the EpochEnd class from TF Watcher to specify that we are interested in operating in the epoch level. There are quite a few of these classes which you can use for your own needs – find out all about the other classes in the documentation.
• We pass in schedule as 1 to monitor after every 1 epoch. You could pass in 3 instead (to monitor after every 3 epochs) or you could also pass in a list of the specific epoch numbers you want to monitor.

When you run this piece of code, you should see something like this printed out:

Unique ID for your session

This includes a unique 7 character ID for your session. Be sure to make a note of this ID as you will use it to monitor your model.

How to Start Monitoring Your Model 🚀

Now we will train the model we built and monitor the real-time metrics for training on a mobile device.

model = get_model()

history = model.fit(
    x_train,
    y_train,
    batch_size=128,
    epochs=100,
    validation_split=0.5,
    callbacks = [MonitorCallback]
)

In this piece of code, we start training our model for 100 epochs (should be pretty quick in this case). We also add the object we made in the earlier step as a callback.

If in your case you are monitoring the prediction instead of training, you would add callbacks = [MonitorCallback] in the predict method.

Once you run the above piece of code, you can start monitoring it from the web app from your mobile device.

Go to https://www.tfwatcher.tech/ and enter the unique ID you created above. This is a PWA which means you can also install this on your mobile devices and use it as a native android app, too.

Install the web app

Once you add your session ID you should be able to see your logs progressing in real-time through the charts. Apart from the metrics, you should also be able to see the time it took for each epoch. In other cases this might be time taken for a batch, too.

The monitoring dashboard

How to Share Dashboards

Since ML is highly collaborative, you might want to share your live dashboards with colleagues. To do so, just click the share link button and the app creates a shareable link for anyone to view your live progress or stored dashboards.

Here is the shareable link for the dashboard I created in this tutorial.

What Else Can You Do with TF Watcher?

Though the example I just showed looked quite cool, there is a lot more we can do with this tool. Now I will briefly talk about two of those scenarios: Distributed Training and non-eager execution.

Distributed Training

You might often distribute your Machine Learning training across multiple GPUs, multiple machines, or TPUs. You're probably doing this with the [tf.distribute.Strategy](https://www.tensorflow.org/api_docs/python/tf/distribute/Strategy) TensorFlow API.

You can use it in the exact same way with most distribution strategies with limited use while using ParameterServer in a custom training loop.

Distributed training

You can find some great examples of how to use these strategies with TensorFlow Keras here.

Non-eager execution

In TensorFlow 2, eager execution is turned on by default. But you will often want to use tf.function to make graphs out of your programs. It's a transformation tool that creates Python-independent dataflow graphs out of your Python code.

One of the earliest versions of this project used some Numpy calls but guess what, you can now use the code in the same way in non-eager mode too.

Thank you for reading!

Thank you for sticking with me until the end. You can now monitor your Machine Learning projects from anywhere on your mobile device and take them to the next level. I hope you are as excited to start using this as I was.

If you learned something new or enjoyed reading this article, please share it so that others can see it. Until then, see you in the next post!

You can also find me on Twitter @rishit_dagli.

While it may seem like this is a straightforward affair, you’ll soon realize it takes a bit of work to get this functionality working.

First and foremost, it is important to realize that (at the time of writing this article) Flutter does not have built in support for embedded WebViews.

Unlike a native application in either Kotlin or Swift where you can just instantiate a WebView component, you cannot add a WebView component to your Flutter application out of the box.

In this article, we'll go over how to configure WebView in Flutter applications, and how to communicate between Flutter and Webview.

How to configure WebView in a Flutter application

After creating a new Flutter project, we need to use the webview_flutter package to be able to use a WebView. We will add the dependency to our pubspec.yaml file:

dependencies:  
       flutter:    
           sdk: flutter
       webview_flutter: ^1.0.7

Then, we need to run pub get in the terminal:

flutter pub get

Next, we import the package in our main.dart file:

import 'package:webview_flutter/webview_flutter.dart';

If you haven’t cleaned up the code from the starter project yet, now is a good time to do so.

After you remove all the comments, the floating action button and everything related to it, you will be left with this (I added a text widget just for show):

import 'dart:convert';

import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Communication Bridge',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: MyHomePage(title: 'Native - JS Communication Bridge'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {

  WebViewController _controller;

  @override
  Widget build(BuildContext context) {
    return Text(
      "Flutter JS-Native Communication Bridge"
    );
  }
}

Which will give you this result:

Creating a local HTML asset

Since we will be using a local HTML file with embedded JavaScript code inside of it, we need to create it in our project.

All local assets in a Flutter application need to be in an assets directory.

Create an assets directory in your main project hierarchy by right clicking in the left side panel and choosing New → Directory:

The file hierarchy after creating the asses directory

Then, go on ahead and create index.html inside the assets directory and add the following code:

<html>

    <head>
        <title>My Local HTML File</title>
    </head>

    <body>
        <h1 id="title">Hello World!</h1>
        <script type="text/javascript">
            function fromFlutter(newTitle) {
                document.getElementById("title").innerHTML = newTitle;
                sendBack();
             }

             function sendBack() {
                messageHandler.postMessage("Hello from JS");
             }
        </script>
    </body>
</html>

You will notice that we have written two methods in the JavaScript section of our html:

1. fromFlutter is the method we will call from Flutter with a string representing the new title for the page
2. sendBack is the method we will call to communicate back to Flutter. In it we are sending a string message.

We will get into the contents of sendBack in a minute, but before that, we have to set up our WebView in our application.

✋ Don’t forget to add index.html to your pubspec.yaml under an assets section (use the correct indentation):

dependencies:
  flutter:
    sdk: flutter
  webview_flutter: ^1.0.7
  cupertino_icons: ^1.0.0

dev_dependencies:
  flutter_test:
    sdk: flutter

flutter:
  uses-material-design: true

  assets:
    - assets/index.html

Set up the WebView

Since we already imported the package into our main.dart file, we need to replace the Text widget with a WebView widget:

class _MyHomePageState extends State<MyHomePage> {

  WebViewController _controller;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Webview')),
      body: WebView(
        initialUrl: 'about:blank',
        onWebViewCreated: (WebViewController webviewController) {
          _controller = webviewController;
          _loadHtmlFromAssets();
        },
      ),
    );
  }

  _loadHtmlFromAssets() async {
    String file = await rootBundle.loadString('assets/index.html');
    _controller.loadUrl(Uri.dataFromString(
        file,
        mimeType: 'text/html',
        encoding: Encoding.getByName('utf-8')).toString());
  }

}

We wrapped our WebView with a Scaffold widget (we'll go over this more later in the article), but let’s focus on the different fields of the WebView widget seen above:

• initialUrl is where we can define which URL the WebView points to. Here we decided to point it to nothing since we are going to load our local HTML file
• onWebViewCreated is a callback we get from the package once the WebView is created. Since we want to save the controller instance that we get from this callback, we have created a private member to store it to, _controller

You will also notice that we created a method called _loadHtmlFromAssets, which as is implied by its name, will load our local HTML file into the WebView.

Inside this method, we use our private WebViewController instance, _controller, and it’s exposed method loadUrl to load our local HTML file. Due to the logic in this method, its execution is asynchronous.

If we run our application, we will get the following:

How to communicate from Flutter to WebView

Now let’s add some functionality to call the fromFlutter method we defined in our local HTML file.

To do that, we will be adding a Floating Action Button (or FAB) to our layout and connecting its onPressed method to call the fromFlutter method.

This is also the reason behind the usage of the Scaffold widget – so we can easily add a FAB:

@override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Webview')),
      body: WebView(
        initialUrl: 'about:blank',
        javascriptMode: JavascriptMode.unrestricted,
        onWebViewCreated: (WebViewController webviewController) {
          _controller = webviewController;
          _loadHtmlFromAssets();
        },
      ),
      floatingActionButton: FloatingActionButton(
        child: const Icon(Icons.arrow_upward),
        onPressed: () {
          _controller.evaluateJavascript('fromFlutter("From Flutter")');
        },
      ),
    );
  }

In order to make calls from Flutter to our loaded HTML we are using the evaluateJavascript method. To be able to use it, we must add another property to our WebView called javascriptMode.

In the code above, we are setting it to unrestricted. If we don’t set it, we will not be able to communicate between Flutter and the WebView:

How to communicate back from WebView to Flutter

Remember how I said we will talk about the contents of our sendBack method? Let's do that now:

function sendBack() {
  messageHandler.postMessage("Hello from JS");
}

In the sendBack method, we are using an object called messageHandler, and it’s attached method called postMessage.

Just like creating a communication bridge in a native application, once you set one up, you are adding an object to the global Window object in the JavaScript layer to be used for communication.

You can name this object to whatever you like as long as you reference it when you make calls from JavaScript to your native application.

How is this object added to the JavaScript layer in our application, you might ask? By adding the JavascriptChannels attribute to our WebView widget:

class _MyHomePageState extends State<MyHomePage> {

  WebViewController _controller;
  final GlobalKey<ScaffoldState> _scaffoldKey = new GlobalKey<ScaffoldState>();

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      key: _scaffoldKey,
      appBar: AppBar(title: Text('Webview')),
      body: WebView(
        initialUrl: 'about:blank',
        javascriptMode: JavascriptMode.unrestricted,
        javascriptChannels: Set.from([
          JavascriptChannel(
              name: 'messageHandler',
              onMessageReceived: (JavascriptMessage message) {
               _scaffoldKey.currentState.showSnackBar(
                  SnackBar(
                      content: Text(message)
                  )
                 );
              })
        ]),
        onWebViewCreated: (WebViewController webviewController) {
          _controller = webviewController;
          _loadHtmlFromAssets();
        },
      ),
      floatingActionButton: FloatingActionButton(
        child: const Icon(Icons.arrow_upward),
        onPressed: () {
          _controller.evaluateJavascript('fromFlutter("From Flutter")');
        },
      ),
    );

  }

We have defined a JavascriptChannel with a name and an onMessageReceived handler. The name we have given this channel, messageHandler, is the name we are using to communicate from the local HTML file we loaded to our native layer.

Great success

For the keen eyed, you probably noticed that a new private variable has been added, _scaffoldKey. This is because we needed to add a key to our Scaffold widget so we can display the snackbar.

You can get the source code for the application described in this article below:

Two final points to be aware of:

1. The alert method is broken in the webview_flutter package
2. To use the package in iOS, you must add the following key to your info.plist file: <key>io.flutter.embedded_views_preview</key><string>yes</string>

Here are some other sources you may find helpful if you want to learn more about Flutter and WebViews:

• The Power of WebViews In Flutter
• WebView_Flutter Package

The amount of time people spend on their mobile phones has increased over the years, and so has the number of people using mobile devices.

It’s safe to say that mobile has almost completely taken over the desktop. With the number of users crossing over to mobile, it has become essential to create apps that can provide a seamless and engaging mobile experience.

For a business, there are plenty of ways in which an app can be helpful. Some of these include:

• Improving sales and revenue generation.
• Building a community and increasing engagement by providing the audience with resources.
• Improving employee communication with internal business apps.
• Improving mobile marketing strategy and increasing brand awareness.

Even though there are many positives to it, creating an app can be tedious and intimidating. It can also be costly, risky, and can take a lot of time.

But if you create the app well enough, it will be worth everything in the end. To create a smart mobile app that beats the competition, here are some tips.

Define the app objectives

The first step before you even start creating a mobile app is defining your reasons and clearly stating the app’s objectives.

If you don’t have clarity about small details like this, it will affect your planning and app building. In the end, you are not likely to get what you want.

There are two things that you must try to satisfy with your app. First, the ideal goal of users, and second, the purpose of your business.

To determine these, you have to ask yourself specific questions:

• Which parts of your business do you need to improve?
• How can an app help solve the problem?
• What are the possible results that you might get?

Some other areas of your business that you also have to consider are your budget, timeline, market research, and so on.

State the functions and features of the app

After stating the purpose and objectives of your app clearly, your next step would be to define the scope of your mobile app. At this point, you start to determine what the app will look like and the features that it will have.

You need to be creative and make a list of necessary functionality and features to achieve your desired results.

Some features that you may include in your app are:

• eCommerce integrations
• Social sharing
• Chat
• Push notifications
• Forms
• Contact form

Write down all the valuable features and let this guide you through your app development process.

Research app competition

Although you already are sure of what you are building and what you need in your app, you might want to look at some of your most successful competitors. Consider what they are doing with their apps and how it is helping them reach similar goals.

Be sure not to look at just your local competition. Research some of the bigger companies in the same industry that reach out to a similar audience in your country or other parts of the world. With this, you can get inspired and get new ideas you can use in the market.

Some of the things that you have to consider are app layout, features, and functionalities. Look out for other things that stand out or things that you might be missing.

Plan the UX and user journey of the mobile app

UX of an App

The success of mobile apps depends a lot on the User Experience of the app. You have to make sure that your app’s functions align with the users’ desires and expectations. You must plan your User Experience in advance.

If you don’t plan the app’s user experience, you will not have an idea of how complex the app is. You also will not realize how much time you need to invest in developing the app. In the end, you won’t have something tangible to present during user testing.

Make sure that the users have a low UX resistance with the app. The primary goal here is to ensure that they find the solution in the most efficient and intuitive way possible.

If you don’t take the time to plan the UX before you start to build correctly, your users will likely experience difficulty with their use of the app. Then you would need to spend more resources and time to fix things.

The significant difference between a successful app and an unsuccessful one is the user experience. Poor user experience can stem from making some avoidable mistakes when building the app. Some of the mistakes to avoid for good user experience are:

Not understanding the needs of the user

The very foundation for building a good app is understanding what users need. Having an understanding of your audience is crucial. You have to consider the users’ pain points, how your app is better than your competition, and the interface.

Adding too many features

If it's your first time developing a mobile app, you might be tempted to add a lot of features you think are cool.

But this actually relates to a poor user experience most of the time. These features can overwhelm users and make them ditch your app.

Creating poor and confusing navigation

No matter how good the onboarding experience is, if users cannot find what they want easily, then your app is less useful.

Your app should have clear navigation that makes it easy for even first time users to do what they want. There are different types of navigation, so you have to choose what you think is the most intuitive for your app.

Other mistakes that you can make that lead to poor user experience are:

• Neglecting the experience of first-time users.
• Overcrowding the user interface
• Using jargon and terminology that users don’t understand.

Launch the app

The last step to creating a mobile app is to launch the app. Following the launch, you should be open to user feedback and improve the app with regular updates based on user experience.

Conclusion

It takes a lot of time, effort, and resources to create a mobile app. So if you want to create one that outsmarts the competition, you have to do more. It takes a lot of effort, and we’ve highlighted some of the key things you should do in this article.

Whatever it takes, make sure to put the user experience first. Focus on satisfying them and solving their problems with the app, and you are already halfway there.

In this post, I'll share my entire journey about how I became a professional mobile developer.

I hope that reading about my experience will help you reflect on your present and your future, and will either help you start your career as a developer or motivate you to move forward in achieving your goals.

My university degree and how it all started

I finished high school with a mathematics-informatics degree in a small town in Romania.

Like most of my friends, you had two choices in terms of cities to go to for university. I chose Bucharest, the capital of Romania.

I grew up thinking that university is a mandatory thing. That probably happens in most countries.

All our parents want it for us.

I never felt a desire to choose a specific degree. Sound familiar? Never saw myself working as something after I graduated.

In the end, I chose to go to an economics university in Bucharest. Again there were two options. One was considered a good university, and another where you would pay a lot of money just to get a degree.

I took some exams at the first one, without studying, to be honest. And obviously I did not pass.

I had to go with the second option.

Fast forward and I graduated from my economics university. But I graduated two years late. I never had a passion for economics and never saw myself working as a banker. I always thought I wanted to get the diploma, and that's it.

I never considered how much I paid for that useless degree, but I needed a diploma to be accepted by society, right?

I was a failure, with an economics degree, but no experience or knowledge. In the following years, with the help of my family, I managed to create two businesses that failed, too.

I will not discuss those in the story, but let's just say that I learned a lot. I also played online poker, and I was pretty good at it.

Seven years after graduating from high school I found myself with no job experience, no successful business, and no money.

I knew I had to take action, and I knew that all my dreams about having a successful business would not happen soon unless I had a backup plan.

That's when I thought:

What job can I get that will make me happy, pay me well, and allow me to have a good life at 30 - 40 years old, even if I never manage to create my own business?

The only answer that came to mind was programming. I had some prior experience in high school and built a few websites.

There was only one problem – I did not like mathematics in high school, and I always thought that I would not be able to learn professional programming without an excellent understanding of it.

I was wrong.

There are probably a lot of people like me, people who have the same thoughts and doubts. But all you have to do is take action and start learning.

Learning Android and Java

It was 2014 when I first started looking into the idea to learn to code.

First thing I did was to Google for some courses in Bucharest, and I found a company that invited me to their offices. I went there, and I remember they had a lovely furnished office with a lot of iMACs. I told myself, "That's what I need."

Ten minutes later I found that they were doing all their courses online and that it was more like an office to sell the course rather than do the course.

I don't remember the exact price, but it was around 1500 - 2000 USD. I didn't take it.

I let go of the idea for a few months, then 2015 came. New year, new plans, new life, you know?

I started to look into an in person course again, and found out that they were called bootcamps.

Discovered one in Bucharest and they were doing Java, and it only cost around 800 USD for four months. It would be a few hours a day with a teacher and other students.

Looking back, I think they were cheap for what they offered, but I think we were the second batch they had.

They were telling us all kinds of things about being hired after the bootcamp, but I did not care.

I wanted to learn to code, and I thought that I would manage to find a job quickly after just a few months. I was right, but it was not as easy as I thought.

The classes started. They always told us that it is not enough to do only lessons during our hours together.

I tried to listen. But at home, things never made sense. Programming was hard, and I often thought that I would not be able to finish the bootcamp.

I pushed myself harder and harder. It was one month into the courses when I found that we were going to learn Java with Android, but again, I did not care. I was falling in love with Eclipse and things happened on the screen as we coded.

Eclipse is an Integrated Development Environment that was originally used to develop for Android. Now we use Android Studio.

It was hard. Lesson after lesson I was trying to learn variables, classes, inheritance, encapsulation, for loops, and so on.

But I struggled. I didn't have a clear picture of how I could use all these in a bigger app. It did not make sense a lot of times.

If you just started programming and you feel the same, I want you to know that it's normal.

Our mentors always told us: "You do not have to know all these off top of your head. Just try to understand what they are and how you can use them."

They were right, but I found that out later. At that specific moment in time, it did not help.

One thing which I regret is that I did not do projects from the beginning. I always thought that I needed a teacher and that you cannot learn anything online on your own. I was lazy and again, wrong.

After four months, I managed to make my first "non-working" app. It was an app where students could rent rooms from other students or people.

I said "non-working" because it did not have any backend or any users. It was more like a demo app that was using some SQLite for storing data.

I was proud of it, because a few months before, I never imagined I could do it.

The bootcamp finished, and I don't think I ever spoke with anyone from their management again.

Not sure if they tried to get me a job, or maybe they thought I was not good enough for a career as a developer.

First interviews and first job as a Junior Android Developer

I started interviewing, and I remember that my first one was for a Java role at a big international company located in Bucharest. (Hint: they have over 300,000 employees, and their revenue from 2019 was about 77 billion.)

I did not take the interview, but I think that the conversation was a good one. I probably wasn't hired because I didn't have any experience.

After that, it took me another month to get the next interview.

A friend I made in the bootcamp helped by recommending me. If he reads this post, I want to thank him.

The role was actually as an Android developer for a Romanian outsourcing company that had a contract with a telecom company.

I had two interviews with them, mostly technical questions, and I still remember when they called to offer the role.

The salary was small, but it did not matter.

I think I started the bootcamp at the end of May 2015, and I began my first role as Junior Android Developer in January 2016.

It was quite an achievement.

My manager assigned me a project, and then I started learning about version control and how to work Agile, and how to work in 2 weeks sprints.

If you've started learning programming or you want to start, I recommend three things.

• Start today (Optional if you already started)
• Do as many projects as possible
• Learn version control (Git, Bitbucket, or Gitlab) and push all your projects there.

Maybe I will write another article about all these things.

During my time at that company, I met a lot of friendly and helpful people. I was probably annoying to a lot of them because, at the beginning, I was asking for a lot of help.

New country and more Android jobs

9 Months later I decided that I wanted to move to London because I was getting a lot of messages from recruiters. Also I thought that it would be easier to further my career there, then return to Bucharest.

I was lucky that my sister lived there, and she was kind enough to let me live with her.

Even when I had recruiters promising me interviews and stuff like that, when I got there I had zero meetings.

I knew that it would not be easy, and I applied to a lot of jobs online.

After two weeks, I got an interview at a British Telecom services company. They had a small IT department, and their Android developer was leaving. They had internal Android CRMs apps, used by their employees, and they needed someone for maintenance and to develop new apps.

It was a one year contract, and the pay wasn't great (I found that out later), but again, I was happy.

I learned a ton in that year (on my own).

I learned Android specific technologies like:

• What's an architecture like Model-View-Presenter and how to use it in an app
• How to do proper Unit Testing
• The SOLID principles

And so on.

I learned all that at work and in my free time. I was working, and in my spare time, I was building apps for myself.

To this day, all my apps (5 on Android) have more than 100k downloads, mostly organic, but only one of them made more than 2,000 USD.

I worked for the telecom company for precisely one year. I wanted to try something different thing in London and work with more Android developers.

It took me some time to understand that, as a software developer, you always have to do more than what you do at work. It's the same with doctors or lawyers. They regularly need to improve their knowledge to be better than others.

I felt ready to work on a more significant project, but I don't think I was skilled enough.

It did not discourage me, and I took an Android role at a global outsourcing company.

I was going to work for a big British bank in London.

I was scared initially, but it took me one month to feel like I was part of that project.

I did three interviews before I entered the project.

During my career, all the interviews I did had two or three steps.

The first one is usually with HR where they ask you things about your experience.

The second interview could be with technical questions, take-home assignments or technical questions with some algorithms.

The third interview might be with a tech lead or with a manager or again with someone from HR.

I started working at the bank in a proper Scrum team. We were 4 Android devs, 4 iOS devs, a Project Manager, a Product Owner, 2-3 Quality Assurance Engineers, a Business Analyst, Copywriter, Designers.

All these people were developing a crucial part of the app. The project was massive.

Just in the development team there were more than 30 Android and more than 30 iOS developers.

I stayed at that role for one year, like with my previous job. The reason? I wanted to go back to Romania.

I was lucky enough to have only good colleagues around me.

It's never wrong to ask for help if you want to learn. We've all started from the beginning, with zero knowledge. I feel that it's terrible not to want to learn when you don't know.

The year at the bank taught me a lot, and it felt like a few years. I learned:

• How to do code reviews
• How to work on a project that required 100% code coverage for Unit Testing
• How to deliver features on time
• What is clean architecture and how to write code that's easy to read without leaving a ton of comments

And many more that I probably don't remember.

Going back home with more knowledge

It was November 2018 when I went back to Bucharest, after two years and a bit of living in London.

It was an excellent experience, but it did not feel like home.

I got a new job for another outsourcing Romanian company quite fast (2 weeks) after I came back.

It took me only four months to leave again for a new six months project in London.

I was not happy to leave my girlfriend alone, but the money was good for only six months of work.

I'm not allowed to disclose any information about the project because I signed a non-disclosure agreement, and today I'm still working for them. But I'm located in Bucharest right now. I've been working for the current company for more than a year and a half.

What did I learn on this project?

• How to create a team
• How to start a big app from scratch. I will probably be very proud once we launch and people will use it.
• How to adapt requirements with a lot of unknowns.
• How to deliver by working with people all over the world.

It's been a crazy journey.

Conclusion and what I learned

My post is at over 2000 words, and I feel I did not give you a lot of details about what I learned. I only scratched the surface.

It was not easy, but I don't regret choosing this career.

If you are me from 5 years ago, just start.

You will feel like quitting. You will think that you are not smart enough, you will feel like any developer that takes a few hours/days to solve something without any luck and then has a moment of brilliance.

It's not wrong not to know, and no question is stupid. It's terrible if you don't want to learn.

Today, more developers than ever are willing to help. You can easily find Discord groups where people are happy to answer your programming questions. There are a lot of Reddit communities that will be helpful. Maybe even Slack channels can work for you. Finding a mentor can be a solution too.

Websites and YouTube channels like freeCodeCamp are all you need to get started.

Here are all the things I hope you learned in this post:

• Starting is hard, but every day of learning something new will give you enormous satisfaction.
• You need to do all kinds of projects. Knowing the basics is good, but building things and working with version control will help you prepare for a future job.
• People are willing to help (both online and future colleagues)
• There will be days when nothing will work. You will not find a solution easily. Either relax and come back to the problem later or just ask for help.
• All developers (junior, mid or senior) search for solutions on Google and get stuck frequently.
• You will feel impostor syndrome, but trust me when I say that I met developers with CS degrees who are worse than me.
• Being a developer it’s not only about coding. Soft skills are important too.

If you liked this article and want more of this, please follow me on Twitter. I write about my journey as a mobile developer, my failed/successful start-ups, about app marketing, and all kinds of other things I learned in the past 10 years.

If you're developing any type of IoT product, inevitably you'll need some type of mobile app. While there are easy ways, they're not for production use.

In this tutorial, we'll talk about the basics of Particle app development. You'll learn about some of the many app frameworks you can take advantage of. Plus there's libraries, tricks, and tools along the way to make your life a lot easier.

App Frameworks

Sometimes it's dang near irritating to program multiple applications natively. You see, Swift (or Objective C ?) and Java aren't terrible at first glance (well, maybe except for Obj-C ?). But when you're resource constrained, you have to figure out a new game plan. That's where App Frameworks come in.

These frameworks allow an app developer to write, build and test cross platform apps. In some cases, the frameworks convert your app into native code. That means that they run as fast and as well as one written in Swift or Java.

I did the research and as of January 2020, here are some of the most supported frameworks:

• Framework7
• Flutter
• NativeScript
• ReactNative
• Ionic
• Cordova / PhoneGap
• Meteor
• Xamarin

The list goes on for days.

I've used a few of these frameworks in the past. I've built a Meteor app which (surprisingly) worked. In the end I had to pick one though. What did I go with?

NativeScript.

For the most part, NativeScript's documentation and on-boarding experience is fantastic. Not only can you preview your app inside an emulator but you can load it directly to your phone too!

One of the cool things about NativeScript is that it supports TypeScript. TypeScript is a superset of JavaScript with some extra wiz-bang features.

Unlike other languages, JavaScript technically has no types. If you've done any Particle development you likely know what a type is. We're talking about int, String, float and more. i.e. they're directives to to make sure your JavaScript code stays consistent.

NativeScript is also compatible with most major JavaScript web frameworks. This includes Vue.Js and Angular.

I've only noticed one major drawback thus far: the mobile preview mode (tns preview command) does not pay well with native libraries. If you have some native platform specific libraries, you'll have to use the emulator or a device (if you have one).

If you're gung-ho and you want to build multiple apps in their respective languages, the more power to you. There is an advantage over the above frameworks: tried and true Particle SDKs.

Available Libraries & SDKs

Particle has gone out of their way to make app development a little easier. This is thanks to the massive development work that has gone into their own SDKs. Yup, gone are the days you have to write manual HTTP request handlers.

Here's a link to both the iOS and Android SDKs:

• iOS
• Android

Though we won't be covering them here, they reflect all the potential calls that you can make using the Cloud API.

Speaking of Cloud API, Particle has also developed a Node.js library as well. As you can imagine, you can use this for your server side code or JavaScript based app frameworks. Sadly, it doesn't work with NativeScript. Frameworks that use a WebView should be more compatible.

In the case of this tutorial, we'll be mostly focusing on the Cloud API. This way you have a good understanding of the overall system. It may seem intimidating but if you do it right, you'll get the hang of it real fast.

Making API Calls

In NativeScript you can't use libraries like [request](https://github.com/request/request). (Which happens to be the library Particle's very own DMC used in the CLI — DMC if you're reading this, Hi!) You'll have to use the provided HTTP module.

If you scroll all the way to the bottom of that page, you'll see a fully fledged POST example. I'll reproduce it here but with some Particle specific changes:

// Create form post data
var data = new FormData();
data.append("name", "update");
data.append("data", "It's hammer time!");
data.append("private", "true");
data.append("access_token", _token);

// Configure the httpModule
return httpModule
    .request({
        url: `https://api.particle.io/v1/devices/events`,
        method: "POST",
        content: data
    })
    .then(
        response => {
            const result = response.content.toJSON();
            console.log(result);
        },
        e => {
            if (e) console.log(e);
        }
    );

The above is an example of what's equivalent to Particle.publish in DeviceOS. Let's break down the parts.

First of all, one of the main gotchas of Particle's Web API is the data format. I first expected that they use JSON but I was sorely wrong. After actually reading the documentation I realized that most POST requests were actually application/x-www-form-urlencoded. That means when you submit data, it's the equivalent to hitting the submit button on an HTML form.

Fortunately, there is an easy way to assemble form data in Node/JavaScript. We can use the FormData() object. Take a look at the above. There should be some familiar parameter names in the data.append calls.

"name" refers to the name of the event you're publishing to.

"data" refers to the string formatted data that you're publishing.

"private" dictates whether or not you want to broadcast this data to the whole Particle world, or just your little corner of it.

"access_token" is a token that you can generate in order to make these API calls. Without a token though, you're dead in the water.

Getting a Token

Where do we get this elusive access_token?

At first I had no idea.

I created an OAuth user and secret in the console. That lead to a dead end. Fiddled around with different API calls and settings. Nothing. Then it hit me like a ton of bricks. There's an access_token attached to the curl request on every device page!

Open up any device, click the little console button near Events. A popup with instructions an a URL will pop up. Copy the text after access_token=. That is your access_token! See below:

You can use this token to make calls to the Particle API. This can be to subscribe, publish, write to a function, read variables and more.

Through the command line

That's nice and everything but how the heck can you programmatically generate one? One way is with the command line.

particle token create is the name of the command you need to know about. When you run it, you'll be prompted to login. (Also enter your Authenticator code if you use one.) Then the command line will spit out a shiny new access_token you can use with the API!

Through the API itself

If you couldn't guess, particle token create is a frontend to a raw API call. You can make these API calls directly too. Here's what it looks like in NativeScript.

// Create form post data
var data = new FormData();
data.append("username", "jaredwolff");
data.append("password", "this is not my password");
data.append("grant_type", "password");
data.append("client_name", "user");
data.append("client_secret", "client_secret_here");

// Configure the httpModule
return httpModule
    .request({
        url: `https://api.particle.io/v1/oauth/token`,
        method: "POST",
        content: data
    })
    .then(
        response => {
            const result = response.content.toJSON();
            console.log(result);
        },
        e => {
            if (e) console.log(e);
        }
    );

This call may get more complicated. Mostly in the case if you have two factor authorization setup. It's well worth it when you figure it all out. After all, no one wants to manually create auth tokens if they don't have to!

Now you're ready to write and read from your devices. There's one thing though that may trip you up. Subscribing to events can be troublesome with a regular HTTP client. So much so that if you try to do it with NativeScript's HTTP client, it will lock up and never return. Luckily there is a way to handle these special HTTP calls.

Server Sent What?

Server Sent Events (SSE for short) is an HTTP/S subscription functionality. It allows you to connect to a SSE end point and continuously listen for updates. It's a similar web technology to what companies use for push notifications. It does require some extra functionality under the hood though...

SSE Library

After much head scratching and searching I stumbled upon nativescript-sse. It looked simple enough that I could start using immediately. More problems arose when I tried to use it though.

First, it turns out you can't use the library in tns preview mode. The alternative is to use tns run ios --emulator or use tns run ios with your iPhone connected to your computer. The non-emulator command will automatically deliver your prototype app.

Side note: I had already set up my phone in Xcode. You may have to do this yourself before tns run ios is able to find and deploy to your phone.

Secondly, once I got the library working, I noticed I would get some very nasty errors. The errors seemed to happen whenever a new message from Particle came along.

Turns out the underlying Swift library for iOS had fixed this last year. So I took it upon myself to figure out how to upgrade the NativeScript plugin. I'll save you the time to say that it can be a pain and there is a learning curve!

Fortunately after some hacking I got something working. More instructions on how to compile the plugin are in the README. Alternatively, you can download a pre-built one on the Release page of the repository.

Download the .tgz file to wherever you like. Then, you can add it using tns plugin add. The full command looks like this:

tns plugin add path/to/plugin/file.tgz

You can check to make sure the library is installed by running tns plugin list

**jaredwolff$ tns plugin list
Dependencies:
┌─────────────────────┬──────────────────────────────────────────────────────────────────────────────────┐
│ Plugin              │ Version                                                                          │
│ @nativescript/theme │ ~2.2.1                                                                           │
│ nativescript-sse    │ file:../../Downloads/nativescript-sse/publish/package/nativescript-sse-4.0.3.tgz │
│ tns-core-modules    │ ~6.3.0                                                                           │
└─────────────────────┴──────────────────────────────────────────────────────────────────────────────────┘
Dev Dependencies:
┌──────────────────────────┬─────────┐
│ Plugin                   │ Version │
│ nativescript-dev-webpack │ ~1.4.0  │
│ typescript               │ ~3.5.3  │
└──────────────────────────┴─────────┘
NOTE:
If you want to check the dependencies of installed plugin use npm view <pluginName> grep dependencies
If you want to check the dev dependencies of installed plugin use npm view <pluginName> grep devDependencies**

Once installed, invoking the library takes a few steps. Here's an example:

import { SSE } from "nativescript-sse";

sse = new SSE(
            "https://api.particle.io/v1/events/blob?access_token=<your access token>",
            {}

// Add event listener
sse.addEventListener("blob");

// Add callback
sse.events.on("onMessage", data=>{
    // TODO: do stuff with your event data here!
    console.log(data);
});

// Connect if not already
sse.connect();

First you need to import and create an instance of the library. When you create the instance, you will have to enter the URL that you want to use.

In this case we'll be doing the equivalent of Particle.subscribe(). It should look something similar to the above: https://api.particle.io/v1/events/<your event name>?access_token=<your access token>.

Replace <your event name> and <your access token> with the name of your event and your freshly created token!

Then you set up the library to listen for the event you care about. In this case blob is the event I most care about.

Then make sure you configure a callback! That way you can get access to the data when blob does come along. I've made a TODO note where you can access said data.

Finally, you can connect using the .connect() method. If you don't connect, SSE will not open a session and you'll get no data from Particle.

Placement of the code is up to you but from the examples it looks like within the constructor() of your model is a good place.(https://github.com/jaredwolff/nativescript-sse/blob/master/demo/app/main-view-model.ts)

Other Examples

If you're curious how to use SSE in other places I have another great example: Particle's CLI.

Particle uses the [request](https://github.com/request/request) library to handle SSE events in the app. Whenever you call particle subscribe blob it invokes a getStreamEvent further inside the code. You can check it out here. The request library has more information on streaming here.

More resources

This is but the tip of the iceberg when it comes to connecting with Particle's API. Particle has some great documentation (as always) you can check out. Here are some important links:

• API documentation
• Javascript SDK
• iOS SDK
• Android SDK

Conclusion

In this post we've talked about app frameworks, NativeScript, NativeScript plugins and Server Sent Events. Plus all the Particle related things so you can connect your NativeScript app to Particle's API.

I hope you've found this quick tutorial useful. If you have any questions feel free to leave a comment or send me a message. Also be sure to check out my newly released guide. It has content just like this all about Particle's ecosystem.

Until next time!

This post was originally from https://www.jaredwolff.com/how-to-develop-particle-iot-apps-using-nativescript/

So many people own smartphones these days. This opens up endless opportunities for a business - opportunities which, however, are immediately challenged by the immense number of competitors in the mobile software market.

Mobile apps are surely more convenient than web or desktop platforms. Yet, they are not the most comfortable option that the industry offers.

To hit the highest level of user satisfaction and to outrun competitors, inventive people opt in favor of progressive web apps (PWAs) or accelerated mobile pages (AMPs).

What are these things, and how should you choose the best option? Let’s consider each one-by-one by going through these simple questions:

1. What is a PWA?
2. What is an AMP?
3. How are they similar?
4. How are they different?
5. Why PWAs are better than web pages
6. Why PWAs are better than native mobile
7. Why AMPs are better than web pages
8. Why AMPs are NOT better than native mobile

1. What Is a PWA?

A progressive web application, or PWA, unites the advantages of both web and mobile apps into a single software product. As Google declares, PWAs are “user experiences that have the reach of the web and are reliable, fast, and engaging”. It is a technology that lets you use a website as if it was a native app.

Twitter is one of the major companies using PWAs. To install the app, you open the web version on your phone and add it to your home screen. When you open Twitter from the home screen icon, you will be opening it as a progressive web app.

Fundamentals

PWAs are a highly responsive and easily shareable solution, which can work offline. They store HTML and CSS files in the browser cache and archive them with service workers. This makes it possible to use the web page offline. Service workers are one of the three essential components of a PWA, along with the manifest file and a secure protocol HTTPS.

Service workers are JavaScript code components which play the role of a proxy between the network and the browser.

When you open a web page for the first time, service workers store the necessary data in the browser cache. When you open it for the second time, service workers retrieve this data from the cache even before the app checked network availability.

Not only do they provide the ability to work offline but also they greatly boost the response time. Service workers also manage push notifications.

The manifest file is a JSON file containing all the information about your app. For instance, it contains data about the home screen icon of your PWA, its short name, color palette, or theme.

If you are using the Chrome browser on an Android phone, the manifest file will trigger the automatic installation of the PWA onto your phone.

The secure HTTPS protocol is an absolute must if you develop a progressive web app. While service workers make the very concept of a PWA possible, they are vulnerable to network errors or breaches. Service workers can intercept network requests and modify responses. To ensure data security and network security, the secure protocol needs to be used.

Success stories

Twitter is not the only company that has benefited from PWAs. Check out these case studies published by Google to see how this technology helped popular businesses succeed. Among these companies are Pinterest, Alibaba, The Weather Channel, Lancome, and The Home Depot.

2. What Is an AMP?

AMP stands for accelerated mobile page. It's a mobile-friendly web page, which is designed to be loaded instantly. It is a fast and smoothly loading solution which is developed with the user experience in mind. Introduced as an open-source project, the AMP technology was integrated by Google in February 2016.

In 2016, The Guardian announced that their platform was now available as an AMP. To help readers see how it worked, they displayed the same article both as a web version and an AMP version.

There were some differences, but they were insignificant. But what you'd notice right away was how much faster the AMP article loaded compared to the regular web article.

*By comparing this illustration with the one I included earlier, you could notice an interesting point. A PWA needs to be installed. In turn, you do not need to install AMP. It is accessed via a different like.

Fundamentals

The idea of AMPs is to reduce the amount of unnecessary content and functionality so that the app displays essential content immediately. The data can be reduced up to ten times. The three essential components of AMPs are AMP HTML, AMP Components, and the AMP Cache.

AMP HTML is a simplified version of regular HTML. AMP HTML does not allow some tags and elements of HTML (for example, forms). To understand better what AMP HTML should look like, check out the required mark-up.

AMP Components are the scripts that enable you to do without JavaScript. The idea of AMP is to get rid of all JavaScript scripts as make pages load more slowly.

But this does not mean that your page should do without animations, modified layouts, analytics data, autocomplete suggestions, or ads. There is an extensive library of components that enable you to implement these and a lot of other features.

The AMP Cache is a proxy-based content delivery network which fetches and caches page content. AMP Cache enables you as an app owner to easily introduce page updates. It optimizes and, if needed, modifies the AMP.

Success stories

The same as with PWAs, companies are often very proud of the business advantages that AMPs offer. Here is a collection of success stories and case studies of companies that used AMPs and benefited from them. Musement, RCS MediaGroup, CNBC, The Washington Post are all companies that have implemented or plan to implement AMPs.

3. How Are PWAs and AMPs similar?

Both PWAs and AMPs are methods of displaying web pages on mobile devices. Both of them are created to enhance the user experience.

AMPs and PWAs both help reduce page load time. While AMPs may be slightly more effective in terms of loading speed than PWAs, the difference between AMP and PWA loading times is barely noticeable.

Both technologies are actively supported by Google. There is a PWA page on Google Developers and an AMP page on Google Developers as well.

There are not a lot of other similarities, but this primary similarity is essential.

Now let’s see what the differences are.

4. How Are PWAs and AMPs Different?

Appearance

By using a PWA you do not feel like you are using a web page. PWAs look and feel like a mobile app.

By using AMPs, you are well aware that you are using a web page because it looks the same.

Development

In the case of PWAs, the application code is written either from scratch or with some parts of the existing code.

In the case of AMPs, the existing code of a web page is stripped of unnecessary CSS and JS so that the web page loads faster.

User experience

PWAs offer a much better user experience. They have push-notifications, a home screen icon, and no browser tabs. Also, they are much easier to download and lighter in size than a regular mobile app. PWAs load faster than a regular web version because they are embedded with App Shell. And PWAs can be used when the network connection is down.

AMPs offer a slightly improved user experience since the page loads faster than a regular page. Still, this is the only UX advantage that they offer. Unlike PWAs, AMPs cannot work offline.

Performance

From an SEO standpoint, AMP wins the competition. Google favors these pages and lists them in the carousel of top stories, which can increase your click-through rate.

PWAs, in turn, do not have a direct advantage for SEO. However, better user experience translates into higher retention rates, which helps you win with SEO.

Support

PWAs are not supported equally on all devices, so you may find slight inconveniences when they're displayed on iOS. Also, they do not support all the hardware functionalities, such as Bluetooth, NFC, GPS, or accelerometers.

AMPs are supported by all major browsers on all devices.

Apps they're best suited for

PWAs work perfectly for apps that require user interactions. E-commerce websites, social media, or online learning platforms where the app needs to be responsive and constantly updated can make use of this technology. This is why Twitter uses a PWA, for example.

AMPs are more suitable for platforms with a wall of content, such as online magazines or newspapers. AMPs load content instantly, but the interaction opportunities are limited. This is why The Guardian decided to employ AMPs.

5. Why PWAs Are Better Than Web Pages

If you access a web page on mobile, you will have to deal with browser tabs, slow loading times, and annoying pop-ups. If your device has a relatively small screen or a slow network connection, surfing the web on it becomes unbearable.

This problem is solved by progressive web apps. In a few clicks, you install the app on your phone and get down to using it. No need to type a link, no browser tabs, and no pop-up screens. The app works fast, and it does work if the network connection is down.

Alright, the benefits of this solution are evident, but it seems like native mobile apps could work perfectly instead. No, they would not. Let’s see why PWAs are better than native mobile apps.

6. Why PWAs Are Better Than Native Mobile Apps

To use a native mobile application, you have to find it in the App Store or Google Play catalogs. Then, you have to wait for some time to download it. You might not have enough free space on your device, so you'll need to find some room.

In turn, PWAs are installed and ready to use in seconds. The file size is small (although it's bound to increase while you are using the app and it is caching). Still, the size of the cached data depends on the amount of free storage you have on your device.

As you can see, PWAs seem better than a web or native mobile app. But you should understand that this solution is not universal. Check out my recent article on PWA vs Native to learn when a native app is a better choice than a PWA.

7. Why AMPs Are Better Than Web Pages

As mentioned above, web apps are slow and inconvenient, especially when accessed on mobile devices with small screen size or underpowered hardware.

By getting rid of all the web components that are unnecessary for a good user experience, accelerated mobile pages solve this problem. AMPs perform 4 times faster and use 10 times less data than regular web pages.

8. Why AMPs Are NOT Better Than Native Mobile

Unfortunately, AMPs cannot be a complete substitute for native mobile apps. They cannot be installed on the home screen, they still include browser tabs, and their functionality is limited to some basic stuff.

But for an online newspaper or for an informational website, such as WebMD, it is better to use AMPs rather than a native mobile app. These do not require any additional functionality for displaying page content.

To Wrap Up

Both AMPs and PWAs are powerful technologies. To sum up the results of our initial question - PWAs vs AMPs:

• AMPs will be easier, faster, and cheaper for you to develop
• PWA will offer more benefits.

Just remember - neither of them is a universal solution, and neither is a panacea. Even using AMPs and PWAs together may not meet all your demands. Sometimes you may need to choose more conventional types of software.

If you are still not sure what to choose, our specialists share four questions to understand if you need PWA. In short: We believe that progressive web apps are the future. Accelerated mobile pages are just too simple and limited in functionality to compete.

Do you have an idea for a project?

My company KeenEthics is experienced in both AMP and progressive web app development. If you are ready to change the game and start your project, feel free to get in touch.

P.S.

The original article posted on KeenEthics blog can be found here: PWA vs AMP: What Is the Difference and How Do You Choose?

This is the second part of an article on building a Spotify UI clone with autoLayout programmatically. If you missed the first part, no worries - just please go and check it now.

In this article, we are going to add some mocked pictures and try to make the UI look the same as Spotify's.

This is what we are going to do today ?

This is were we left off in the first part:

The next step is to create customized cells. So let's start by creating one with the name SubCustomCell.

First, create a new Swift file inside the project folder and name it SubCustomCell.swift. This file will contain our custom cell that will represent the Playlist. After creating the file, try to add in the code below and initialize the cell, maybe with backgroundColor, to see the UI changes when we register the cell with the collectionView.

import UIKit

class SubCustomCell: UICollectionViewCell {
        override init(frame: CGRect) {
        super.init(frame: frame)
        backgroundColor = .red
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

Then we register the SubCustomCell inside CustomCell.swift within the init block. Replace UICollectionViewCell.self with SubCustomCell like below.

 collectionView.register(SubCustomCell.self, forCellWithReuseIdentifier: cellId)

Also we need to make a modification on the cellForItemAt method and make it conform to SubCustomCell like the following.

 func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: cellId, for: indexPath) as! SubCustomCell
        // cell.backgroundColor = .yellow

        return cell
    }

You should see the backgroundColor changed to red .

Swift CustomCell

Up until this point everything should be straightforward and clear.

Now we're going to fill the cells with some mocked pictures and create an ImageView inside each cell. I already downloaded some random pictures from pexels.com, but feel free to use any pictures you like (including these). You can find them in the project files on Github.

Let's create the UIImageView inside SubCustomCell.swift and make some constraints.

    let ImageView : UIImageView = {
       let iv = UIImageView()
        iv.backgroundColor = .yellow
        return iv

    }()

And add it to the view within the init block using addSubView.

 override init(frame: CGRect) {
        super.init(frame: frame)
        addSubview(ImageView)

    }

Now let's make the ImageView take up all the space within the cell with the constraints below.

 ImageView.translatesAutoresizingMaskIntoConstraints = false
            ImageView.topAnchor.constraint(equalTo: topAnchor).isActive = true
            ImageView.leftAnchor.constraint(equalTo: leftAnchor).isActive = true
            ImageView.rightAnchor.constraint(equalTo: rightAnchor).isActive = true
            ImageView.bottomAnchor.constraint(equalTo: bottomAnchor).isActive = true

• LeftAnchor represents the left anchor of the cell
• rightAnchor represents the right anchor of the cell
• bottomAnchor represents the bottom anchor of the cell
• topAnchor represents the top anchor of the cell

And by making ImageView 's top anchor equal to the cell's top anchor (and doing the same for ImageView 's left, right, and bottom anchor) it makes the ImageView take up all the space of the SubCustomCell (cell).

Note: first you need to use translatesAutoresizingMaskIntoConstraints to be able to apply the constraints to the elements. Also don't forget to call isActive property and assign it to true – without doing that the constraints won't work and nothing will change.

The ImageView should have an image, so let's add one.

 let ImageView : UIImageView = {
       let iv = UIImageView()
        iv.backgroundColor = .yellow
        // we have >image1< file inside the project 
        iv.image = UIImage(named: "image1")
        iv.contentMode = .scaleAspectFill
        iv.clipsToBounds = true

        return iv

    }()

And if you build and run the app, you should see the results and picture we added to the SubCustomCell.

Cool ?. Now there is an element we should add to the SubCustomCell to finish up. We need a title that will represent the title of the playlist: UILabel.

For the title it will be like this:

 let TitleLabel : UILabel = {
        let lb = UILabel()
        lb.textColor = UIColor.lightGray
        lb.font = UIFont.systemFont(ofSize: 16)
        lb.font = UIFont.boldSystemFont(ofSize: 20)
        lb.text = "Evening Music"

        return lb
    }()

I just put some random text there – you can put whatever you like. The next step is to add the element to the view and give it some constraints. The title will be placed at the bottom of the ImageView.

Add to view:

addSubview(TitleLabel)

Applying the constraints for both the ImageView and the TitleLabel

 ImageView.translatesAutoresizingMaskIntoConstraints = false
            ImageView.topAnchor.constraint(equalTo: topAnchor).isActive = true
            ImageView.leftAnchor.constraint(equalTo: leftAnchor).isActive = true
            ImageView.rightAnchor.constraint(equalTo: rightAnchor).isActive = true
            ImageView.heightAnchor.constraint(equalToConstant: 240).isActive = true
            ImageView.bottomAnchor.constraint(equalTo: TitleLabel.topAnchor).isActive = true



            TitleLabel.translatesAutoresizingMaskIntoConstraints = false
            TitleLabel.topAnchor.constraint(equalTo: ImageView.bottomAnchor,constant: 10).isActive = true
            TitleLabel.leftAnchor.constraint(equalTo: leftAnchor, constant: 5).isActive = true
            TitleLabel.rightAnchor.constraint(equalTo: rightAnchor, constant: -5).isActive = true

And here we go!

We made the picture take up most of the space in the cell, and the rest is taken up by the title. As you can see, you can scroll horizontally in each section and also vertically in the entire screen.

Now we are put some mock data into the cells to make it feel like it's real. For that I created a JSON file that contains some random data for sections and playlists.

First let's create a two structs, Section and Playlist . We create a separate file for each struct.

section.swift

import Foundation
struct Section {
    var title : String
    var playlists : NSArray
    init(dictionary:[String : Any]) {
        self.title = dictionary["title"] as? String ?? ""
        self.playlists = dictionary["playlists"] as? NSArray ?? []

}
}

playlist.swift

//
//  playlist.swift
//  spotifyAutoLayout
//
//  Created by admin on 12/6/19.
//  Copyright © 2019 Said Hayani. All rights reserved.
//

import Foundation
struct PlayList {
    var title: String
    var image : String
    init(dictionary : [String : Any]) {
        self.title = dictionary["title"] as? String ?? ""
        self.image = dictionary["image"] as? String ?? ""
    }

}

And then inside ViewController.swift we create a function that fetches the JSON for us and stores the results in an array.

        print("attempt to fetch Json")
        if let path = Bundle.main.path(forResource: "test", ofType: "json") {
            do {
                  let data = try Data(contentsOf: URL(fileURLWithPath: path), options: .mappedIfSafe)
                  let jsonResult = try JSONSerialization.jsonObject(with: data, options: .mutableLeaves)
                if let jsonResult = jsonResult as? [ Any] {
                            // do stuff
                    jsonResult.forEach { (item) in

                        let section = Section(dictionary: item as! [String : Any])
                       // print("FEtching",section.playlists)
                        self.sections.append(section)
                    }


                  self.collectionView.reloadData()
                  }
              } catch {
                   // handle error
              }
        }
    }

The fetchJson function is called within the ViewDidLoad method. We also have a variable called sections where we store the results:

 var sections = [Section]()

The next step is to pass the data from ViewController to CustomCell. For that we create a variable inside CustomCell which will receive the data for each section:

 var section : Section?{
        didSet{
            print("section ✅",self.section)
        }
    }

We use cellForItemAt inside the ViewController method to pass the data directly to the CustomCell .

override func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: cellId, for: indexPath) as! CustomCell

        cell.section = sections[indexPath.item]

        return cell
    }

Note: we always call self.collectionView.reloadData() every-time fetchJson is called so the block below, inside CustomCell, will be called as well. Check the console, shift + command + C:

 var section : Section? {
        didSet{
            print("section ✅",self.section)
        }
    }

The first thing we change is to set the the section title:

 var section : Section? {
        didSet{
            print("section ✅",self.section)
            guard let section = self.section else {return}
            self.titleLabel.text = section.title
        }
    }

And then you should see that each section has a specific title on the screen ?.

Now it's time to pass the data down to SubCustomCell. We do the same thing as we did above. We need to pass the playlists array, so we create a variable named playlists inside CustomCell.

 var playlists : [PlayList]() //empty

First, we map through the playlists from the JSON. Then we add each playlist with the playlists var.

 var section : Section? {
        didSet{
            print("section ✅",self.section)
            guard let section = self.section else {return}
            self.titleLabel.text = section.title
            // append to playlists array
             self.section?.playlists.forEach({ (item) in
                let playlist = PlayList(dictionary: item as! [String : Any])
                self.playlists.append(playlist)

            })
            self.collectionView.reloadData()
        }
    }

Attention! If you try to run the app it may crash. This is because we forgot to set the number of sections. Since we are now receiving the data from JSON, the number should be dynamic based on the number of sections we have. The number of sections should be equal to the number of sections inside the JSON, so we need to modify numberOfItemsInSection inside ViewController to the below :

   override func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        return sections.count
    }

We do the same thing with the same method inside CustomCell.swift – but here we consider the number of the playlists instead.

func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int {
        return  self.playlists.count
    }

The last step we have to complete is to pass each single playlist Object to SubCustomCell within cellForItemAt in CustomCell.swift.

 func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(withReuseIdentifier: cellId, for: indexPath) as! SubCustomCell
        // here ?
        cell.playlist = playlists[indexPath.item]
        return cell
    }

And we are going to get that data inside SubCustomCell via the playlist variable and finally display the title and image of the playlist.

var playlist : PlayList? {
           didSet{
               print("Playlist ?",self.playlist)
            guard let playlist = self.playlist else {return}
            // The Image ?
            self.ImageView.image = UIImage(named: playlist.image)
            // the playlist title ?
            self.TitleLabel.text = self.playlist?.title

           }
       }

I think everything should work fine now, just as below ?

One last update to the UI: we have to add some padding and margins to the section and playlist titles and make the playlist a little bit smaller.

Let's first add some padding for the section titles. To do that, we need just to give the constant property some number value inside the section cell CustomCell and within setupSubCells:

 collectionView.topAnchor.constraint(equalTo: titleLabel.bottomAnchor,constant: 15).isActive = true

And if you see the entire collectionView come in at the bottom of the titleLabel, all we need to do is add more space by adding 15:

Next we come to the title of the playlist. This will be inside SubCustomCell, and we just need to add more space at the bottom of the ImageView.

 ImageView.bottomAnchor.constraint(equalTo: TitleLabel.topAnchor,constant: -15).isActive = true

We already have the constant there. In order for it to work, the value should be -15

Finally the playlist needs to be a little bit smaller. This is easy: we just make the playlist cell's height and width equal to the section cell's height divided by 2, just like below:

CustomCell.swift

 func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {

        let width = frame.height / 2
        let height = frame.height / 2

        return CGSize(width: width, height: height)

    }

Make the ImageView's height equal to 150 as well.

  //SubCutomCell.swift
  ImageView.heightAnchor.constraint(equalToConstant: 150).isActive = true

And here we go ?.

Perfect! I think that's enough for today – I don't want to make this article too long. So we will have another part where we will add the TabBar and the description, as well as some icons for the playlist.

View the Full source code on GitHub?.

Thanks for your time. I hope I haven't missed anything. If I did please @mention me on Twitter, or if you have any questions or an addition to this post the doors are always open to anyone. Thanks??.

Subscribe to my email list to be notified when the third part of this tutorial is published.

By the way, I’ve recently worked with a strong group of software engineers for one of my mobile applications. The organization was great, and the product was delivered very quickly, much faster than other firms and freelancers I’ve worked with, and I think I can honestly recommend them for other projects out there. Shoot me an email if you want to get in touch — said@devsdata.com.

For 5 years, freeCodeCamp has been helping millions to learn to code for...well...free!

The low cost has opened up a world of opportunity to those that could not afford a bootcamp or the many expensive courses available. However, there has been one barrier to entry for some - the necessity to use a laptop / desktop PC.

Coding on freeCodeCamp has been possible on a mobile device, but it's never been a comfortable experience - until today!

With the 5th birthday of freeCodeCamp comes a wonderful gift to the developer community: the new Command Line Chic interface, which includes a far superior mobile experience than has previously been available.

The new responsive command line chic interface, with a clean mobile text editor

Making the most of mobile coding

Maybe you've tried using your mobile device for coding on freeCodeCamp before and noticed an annoying bug - it's impossible to delete things properly!

If you have encountered this, the cause of the problem is simple - your keyboard suggestions are treating the individual characters as longer strings. I haven't investigated this in detail, but my intuition is that it's deleting the html entity code.

The fix is simple - turn off auto suggestions, or better yet use a dedicated coding keyboard for your device.

This has the added benefit of making they keys you use often for programming (but not natural language) more easily available, such as brackets, braces and other special characters.

Coding keyboards for your mobile device

CodeBoard for Andoid

CodeBoard for Android provides a packed keyboard of all the keys you are likely to need while completing the freeCodeCamp curriculum. The board is a little too crowded on a phone (although I still use it and have gotten used to it), but on a tablet it is a perfect companion.

DevKey for iOs

DevKey for iOs presents a much less crowded interface, while still providing most of the keys you are likely to need. I can't personally endorse this, since I do not have an iPhone - but needless to say it presents a better experience for mobile coding than the standard keyboards.

Coding on the go!

Now that you've supercharged your mobile learning environment, you can take those freeCodeCamp lessons with you wherever you go, without the need for a clunky laptop hotspotting off your phone.

One thing that I'm really looking forward to is using the new interface and my mobile set-up to increase my participation on the freeCodeCamp forum! I've always primarily engaged with the forum on my phone, but have struggled to help with coding challenges due to the previously poor mobile experience. Now, you can expect to get even more help from me and hopefully others!

Happy birthday, freeCodeCamp, and happy coding, y'all!

You can follow my more informal tech ramblings on Twitter @JacksonBates!

Swift is a mother?and it has two sons ?-

• Value Type ??‍♀️
• Reference Type ?‍♂️

But what are their characteristics??‍♂️

Do they behave the same or opposite to each other? ?‍♂️

Swift is a multi-paradigm programming language developed by Apple for iOS, macOS, watchOS, tvOS, Linux, and z/OS.?

Just like other object-oriented programming languages, Swift has classes as building blocks which can define methods, properties, initializers, and can conform to protocols, support inheritance & polymorphism.?

But, wait wait wait…???

Swift has structs also and it can define methods, properties, initializers and can conform to protocols with only one exception of inheritance.?

What? Now I am confused!!! ???

Now let’s spice up your confusion: structs are not only the value types in Swift. Tuples and enums are also value types. Classes are also not the only one used as a reference type. Functions and closures are also reference types. But as a token of relief, we at least know the primary focus & specialization of usage of these types.?

So up to this point, we are left with only one big confusion with the usage of structs and classes.?

So, let’s go and clear the confusions going around.?‍♂️

Storage Locations

There are three types of storage available:

• Register ?
• Stack ☄️
• Heap ?

The objects that have a shorter lifespan are stored inside registers or the stack and those that have a longer lifespan are stored inside the heap.?

A value type stores its contents in memory allocated in the stack, so we can say value types are allocated in the stack in Swift. ?

But there is a common misconception about value types, have you heard it??‍♂️

The misconception is that most people think value types are always stored in the Stack.

❌❌ Wait a minute — this is not the case always. ❌❌

Value types can be stored inside the stack when they are either temporary or local variables. But what if a value type is contained inside a reference type?

In this situation, it can be stored inside the heap memory. ?

Wow…that’s cool!!!?

So the value types can be stored inside the register, stack or heap depending on their lifespan, whether they are short lived or long lived. If it is a local variable it can live inside the stack and if it is a part of class then it can live inside heap memory also.✅

On the other hand, reference type stores its contents in memory allocated in the heap memory and the variable holds only a reference to that memory location where actual data has been stored. ??

How does it work for reference type??

So for reference type, it is quite a common situation when there can be several variables holding the reference to the same memory location.⚔️

When a value type instance is assigned to a variable or passed to a function, the instance is copied and assigned to that variable. But with the reference type, only the reference gets copied and the new variable holds the same reference to the same memory location. ?

Differences in terms of Mutability

There can be two states for a variable:

• ?‍♀ ️Mutable ?‍♀
• ?️‍♂️ Immutable ?️‍♂️

If a value type instance is assigned to an immutable variable, then the instance also becomes immutable. As a result, we can not make any changes to that instance.?‍♂️

If a value type instance is assigned to a mutable variable, then only it makes the instance mutable. ?‍♂️

But things are totally different for reference types. The variable and the instance it is assigned to are totally different. If we declare an immutable variable holding a reference to a class, this means that the reference it is holding will never change. We can not the change the reference and it will always point to the same reference. ?

Structural Types

Values of structural types are compared for equality in terms of their attributes or elements. We can say a value type is equal to another if and only if all of the corresponding attributes are equal. ???

Umm…too many strong words…what do you mean???

Let’s say, we have a Person value type which has attributes like firstName and lastName.

struct Person {
   var firstName: String
   var lastName: String
}

var person1 = Person(firstName: "foo", lastName: "bar")

var person2 = Person(firstName: "foo", lastName: "bar")

Here both person1 & person2 instances are holding the same value for firstName (“foo”) and lastName (“bar”). So as per our understanding, we can say that the two instances are equal to each other since their attributes (firstName & lastName) are holding the same values.

But it’s not only limited to this: in the future, any two person instances holding the same values for firstName & lastName will be equal to each other.

So as per our understanding till this point, we can say that:

Value Types do not have identity, so there can be no reference to them. Value types are faceless.?

What? How can you say that????

var myAge: Int = 21
var friendAge: Int = 21

Both myAge & friendAge are integer type variable with value 21.

Can we distinguish one from the other? ?

No, because they are holding the same value.?

An integer variable with value 21 cannot be different from another integer variable which is also having the value 21. As simple as that.???

Not having an identity gives value types another advantage: if you think practically, then you can imagine if you do not have an identity then anyone with same characteristics can replace or substitute you. ???

The same we can think for us as humans also. If I don’t have an identity then anyone with same characteristics can replace me???. It’s good for us that we have an identity otherwise it would be a great risk to our existence.?

But for value types, they don’t have an identity and it is an advantage to them. ?

What are the benefits of using Value Types?

? No Race Conditions and Deadlocks: ?

For values types in a multi-threaded environment, it is impossible for one thread to mutate the state of the instance while it is being used by another thread. So we can say that there will be no race conditions or deadlocks.

⚔️ No Retain Cycles: ⚔️

When there are two reference type instances that are holding strong references to each other and preventing each other from being deallocated from memory, it is called a retain cycle. Since value types don’t work as a reference, so we can say there will be no retain cycles for value types.

?‍?‍?‍? Automatic Reference Counting: ?‍?‍?‍?

For reference type, Swift uses automatic reference counting to keep track of all the live or active objects and deallocates the instance only when there are no more strong references to it. If we think a little bit, then we can say that it is kind of a heavy operation because Swift runtime needs to keep track of the objects always. But since value types are allocated in the stack, it does not need ARC. So it is cheaper and faster??.

But wait...How does it manage memory for Array, Dictionary and String??

Since we can not know what will be the actual size of an array, a dictionary, and a string at compile time, there is no scope for them to be allocated at compile time. Though they are value types internally, they can not be allocated in stack. They need to be allocated in heap memory, and to manage this, Swift comes up with copy on write.?

But what is this??

When we say one instance is a copy of another instance, this really means they are the same, that they contain the same values. But in Swift, for these above types (Array, Dictionary, String, etc), an actual copy has been made on heap only when an instance is mutated. This is called a performance optimization technique for value types.???

Conclusion

There is no hard rule which defines when to use value type and when to use reference type. Value types have some unique advantages over reference types and vice versa. They both are unique in their own way. It really depends on your requirements and what you are trying to achieve. You should know the semantics of your code because you only know your code best, so it’s up to you to choose. You have the full freedom.

So rather than fighting over value type vs reference type, use them intelligently.

??? Cheers!!! Thank you for reading!! ???

✅✅✅You can find me on Twitter.✅✅✅

Dev Ops, Mobile Engineer, Data Scientist, Project Manager, and Front End — what’s best for you?

_Get more info before you blindly choose your future career path. Photo by [Unsplash](https://unsplash.com/photos/ZFYg5jTvB4A?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Robert Anasch on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=").

I’ve worked in tech for four years, and I still come across roles that I don’t understand very well. There are so many ways to build a career in tech. I know that when I started looking for my first job, I was clueless about the differences between career paths. If you asked me what a site reliability engineer did, I wouldn’t have been able to tell you.

I get a lot of questions about career paths in tech. I thought I would write an article about it so I could point people to it. I’ll be using Business Insider’s article listing the 20 best tech jobs in America in 2018 as a reference. This is a good list of relevant tech paths with good upward mobility. They are highly in demand and will allow you to get a job at a good company with good pay. Hopefully, this will help you decide the path you will take. So let's start:

_Mobile devices have deeply integrated into our lives. For better or for worse. Photo by [Unsplash](https://unsplash.com/photos/5AYP1yeaE3I?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">rawpixel on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Mobile Developer

What do they do?

Mobile developers are the people that build apps for companies. If you’ve ever used an Android or iOS device, then you’ve directly interacted with a mobile developer’s work. There are other development platforms for mobile such as Windows phone. But for the most part, when people say “Mobile Developer”, they’re most likely talking about an Android or iOS developer.

Why should I choose this career path?

You should become a mobile developer if you want to use your eye for design and attention to visual detail alongside your technical prowess. Mobile developers work heavily with designers to put out beautiful, easy to use and performant mobile apps.

You should also choose this path if you are interested in mobile devices and how they work. Mobile developers that focus on infrastructure have to consider limited device resources. They also must have in-depth knowledge of how a mobile device works to make the apps they work on performant.

How do I get started?

This depends on if you want to focus on iOS or Android. I’d personally recommend learning Android for two reasons. Java is probably a more useful language to learn over Swift or Objective-C and the fact that 75% of the world uses Android compared to 21% using iOS. This is according to statcounter.com. That being said, if you have a particular passion for one platform over the other, go with your passion.

For Android, read this article. This goes over the nitty-gritty of how to get started. For iOS, watch this video on raywenderlich.com. Ray Wenderlich’s website is an excellent resource for iOS in general.

_Insights derived from data tend to deliver better results than gut feelings from founders. Photo by [Unsplash](https://unsplash.com/photos/1K6IQsQbizI?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Franki Chamaki on <a href="https://unsplash.com/search/photos/data?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Data Scientist

What do they do?

Data scientists help businesses solve problems through the processing of data. So what does that mean? A software engineer will implement some logging somewhere on a website or mobile app. This gets processed and eventually gets to the data scientists. The data scientists will then gather all these data points and derive insights from them.

We can use an e-commerce website as an example. After looking at a few different data points, a data scientist notices that only 0.5% of people that add an item to the cart end up making a purchase. The data scientist then hypothesizes that this could be the reason for the decline in revenue last month. They check the rate three months ago and see that it was at 5%.

It looks like that is probably the reason for the drop in revenue. They surface this to the right stakeholders. These stakeholders find out that there was a crash occurring during purchasing that caused the problem. This may not have been found if a data scientist didn’t work at the company.

Data scientists can also work to spot new paths to growth and ways to improve current products based off of data. The sky is the limit on how a data scientist can be leveraged at a company.

Why should I choose this career path?

Become a data scientist if you love looking at data and trying to see patterns. Data scientists provide value by looking over data and trying to discover insights that will help their company grow. You have to love trying to come up with reasons for why specific patterns are occurring. You also have to have a deep understanding of the products you are working with, so you can vet hypotheses around your data insights.

How do I get started?

I would start with this course on Coursera which first gives you a better understanding of how data drives business decisions. If that course deepens your interest, start with this article that recommends some great ways to start learning.

_Being a project manager requires maintaining a perfect balance between delivery date and quality. Photo by [Unsplash](https://unsplash.com/photos/flEStjHTY14?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Leio McLaren (@leiomclaren) on <a href="https://unsplash.com/search/photos/balance?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Project Manager

What do they do?

Project managers do exactly what their title implies, they manage products. But what exactly does that mean? Well, as a project manager, you need to have a high level view of the product you are working on.

You need to make sure everyone is executing and working on the most relevant tasks so you can ship your product on time. You need to understand what every person on the team is doing, how they’re doing it and when they’ll be done. You line up all the pieces so that the final product has everything it needs in the timeline you provided to the higher-ups.

This also means you need to help unblock people when they’re stuck. You need to organize meetings with other teams if you are dependent on them for finishing your product. You need to run sync up meetings for your team to ensure everyone is on track and not having issues.

The hardest part about being a project manager is ensuring that everything gets done on time and with quality. You also need to make sure the people on your team aren’t overwhelmed. This is always a delicate balance.

Why should I choose this career path?

You are organized and love collaborating with others. You are able to balance the needs of many in order to deliver on a high quality product. You understand the trade off between time and quality and know when to push back for either.

Lets say the people waiting for your product demand that you finish it in 2 months when you know it will take 4 months to deliver a quality product. You must have the ability to provide convincing evidence for why you need the extra time. You also have to ensure that you don’t bow to pressure.

Being a project manager requires maintaining a perfect balance between delivery date and quality.

The opposite can be true also. Sometimes developers say that something will take 1 month when you’ve seen it done in 3 days before. You ask questions and find out that the developer wants to over-engineer this certain piece of work even though you know the product doesn’t need it. You have to figure out a way to get the developer to only build what is needed.

Like I said before, being able to work effectively with others while being organized and keeping a product on track is what it is all about. This is incredibly difficult. You need to have high level knowledge of a product but deep enough knowledge about every piece that you can keep people accountable for their work.

How do I get started?

A lot of project managers in tech use Agile and Scrum methodologies to organize their work. I would get started by looking into obtaining Scrum certifications. Take a look at the Scrum website for more details.

Project manager’s tend to have a business administration degree or a project management degree. If you are already working on a computer science degree, you can consider getting a minor in one of these subject areas.

Another great way to get into project management is to manage a small project with your friends or an open source project. Practice makes perfect and real life application of project management skills will make you stand out as a candidate.

You can also start getting familiar with project management tools such as Trello, Jira, Quip, Excel and many more. Being familiar with the software a project manager uses will help you build your skills in project management.

_Having a sleek front end is key in creating popular websites. Photo by [Unsplash](https://unsplash.com/photos/V09Io5ln-Qo?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Aaron Huber on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Front end engineer

What do they do?

Front end engineers use HTML, CSS and JavaScript to build UI for websites. They focus on aspects that are important to the website such as accessibility, security, usability and performance. If you’ve ever logged into a website or bought something from an e-commerce store on your web browser, then you’ve interacted with a front end engineer’s code. Check out this awesome article for even more details.

Why should I choose this career path?

In a lot of ways, this job is similar to a mobile engineer’s job. They both build UI and should have a certain attention to detail when it comes to visual elements. They both work with designers to implement UI that is both performant and a delight to use. The main difference would be the languages and tools used and the fact that mobile developers are creating applications instead of websites.

You should be a front end engineer if you are the kind of person that likes learning and using new languages and tech stacks. Being a front end engineer requires the use of HTML, CSS, JavaScript and SQL. On top of that, you will most likely need to know some back end server-side framework like Django, Ruby on Rails, or .Net.

Another reason to consider this path is if you are interested in problems around scaling. A mobile application will only ever serve one user at a time. This is due to the fact that only one person can use a mobile device at a time. A website has to serve potentially millions of people at the same time. This requires a different mindset and approach to prevent bottlenecks from occurring.

How do I get started?

This one is easy :) Just checkout freeCodeCamp’s course. This will give you all the skills you need to become a proficient front end engineer.

_From committed code to delivery to production, a DevOps engineer has got you covered. Photo by [Unsplash](https://unsplash.com/photos/0wsnJWonXFs?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Drew Beamer on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

DevOps Engineer

What do they do?

This is by far the hardest role to explain. Because there is a lot of debate about whether this is really a role or actually just a mindset. The idea can be broken down into the fact that a DevOps engineer takes on both a developer and an operations job. Hence the term “DevOps”. Let’s look at each of these roles.

In general, software engineers want to build as many features as possible so they will look good to the higher ups. One of those new fancy features is bound to help the company grow which makes the software engineer look good.

An operations engineer wants stability. Which means they don’t want software engineers to release too many new features. Because with new features comes unpredictability. And with unpredictability, comes instability. The operations engineer just wants every new release to be stable. They want the release process to go smoothly. But releasing too many features or features of high risk threatens this goal, which is exactly what most software engineers are aiming to do.

These two roles obviously seem at odds but that is why a DevOps engineer can be so useful. A DevOps engineer can bridge the gap between development and operations. By doing this, they create meaningful communication routes between these sometimes silo-ed areas. A DevOps engineer creates a feature and sees it safely to production where it makes users satisfied. Being able to do this is highly valued at any company.

Why should I choose this career path?

You should choose this career path if you are not only interested in coding features, but want to learn about how to release your code to a production environment. You should have the drive to learn about every aspect of software engineering and release engineering.

You will most likely need years of experience to be termed as a “DevOps” engineer due to the vast amount of knowledge and tools you will need to learn. You should love learning new things. The idea of knowing every aspect of your tech stack should excite you. If you want to become the person that everyone goes to when something unexpected happens, then you should look into becoming a DevOps engineer.

How do I get started?

I’d get started by learning about how code gets released into a production environment for starters. This can be done by building your own website, and deploying it yourself. The best way is to work for a company for a while and work on every part of the deployment process. Volunteer to fix problems that others don’t want to deal with. That is a great way to learn.

Other than that, I’d recommend reading this article on how to get into DevOps. It is very well written gives even more actionable ways to become a DevOps engineer.

Didn’t see the role you were looking for?

If you enjoyed my summaries of these roles but didn’t see the role that you wanted, leave a comment! I will do another round of these career path overviews for the most clapped comments. Hopefully you enjoyed these summaries of these tech career paths. My hope is that you at least have a better understanding of the breadth of skills and knowledge it takes to release good tech to the world.

I will do another round of these career path overviews for the most clapped comments.

Liked what you read?

Read about how I went from being a broke English teacher in Japan to working at a top tech company in just a few years!

Do you need a computer science degree to get a job in tech?

Passing your first tech interview: how to prepare.

Swift vs. Objective-C. How do they compare?

One Friday this July, I got excited about McDonald's. So excited that I stopped at one before work in the morning and left with French fries and a coffee.

Fries for breakfast.

McDonald's had just announced that it would be giving out free medium fries every Friday with a minimum purchase of $1 through…