SwiftData was introduced in iOS 17, and it’s Apple’s modern native persistence framework built specifically for Swift and SwiftUI.
It brings a type-safe, Swift-native API to model, store, and query data without the old and boilerplate of Core Data or the manual SQL management of SQLite.

In this tutorial, we will build a Movie app demonstrating CRUD (Create, Read, Update, Delete) operations with SwiftData, and also see how it stacks up against Core Data and SQLite.

Why SwiftData?

Before SwiftData, we typically had three main choices for persistence on Apple platforms:

SwiftData vs Core Data vs SQLite

API Style

SwiftData: Designed with Swift-first, declarative syntax in mind. Feels natural alongside SwiftUI.

Core Data: Stems from the Objective-C; Swift support is bridged, which can lead to verbose and less type-safe code.

SQLite: Pure SQL commands, powerful but entirely manual.

Learning Curve

SwiftData: Low, especially if we are already building SwiftUI apps.

Core Data: Medium to high, due to concepts like tables, models, and fetch requests.

SQLite: High, as it requires knowledge of SQL syntax and manual schema handling.

Integration with SwiftUI

SwiftData: Native-with @Query for fetching and @Model for persistence.

Core Data: Possible but requires large code implementations

SQLite: Entirely manual binding to SwiftUI views.

Boilerplate

SwiftData: behind the scenes, everything is handled automatically.

Core Data: Significant entity descriptions, managed object contexts, migrations.

SQLite: Very high, we have to handle every table, query, and migration.

Project Overview

Our Movie app will:

Display a list of movies

Add new movies

Edit existing movies

Delete movies

Model:

SwiftData works around @Model classes, which automatically become persistent entities.

import SwiftData

@Model
class Movie {
    var title: String
    var year: Int
    
    init(title: String, year: Int) {
        self.title = title
        self.year = year
    }
}

App Entry Point

We set up the model container at the app’s root:
This tells SwiftData to persist instances of Movie automatically.

@main
struct SwiftDataCRUDApp: App {
    var body: some Scene {
        WindowGroup {
            NavigationStack {
                MovieScreen()
            }
        }
        .modelContainer(for: [Movie.self])
    }
}

Reading Data

SwiftData’s @Query property wrapper fetches data reactively

struct MovieScreen: View {
    @Query(sort: \Movie.title, order: .forward) private var movies: [Movie]
    @State private var isAddMoviePresented = false

    var body: some View {
        MovieItemView(movies: movies)
            .toolbar {
                ToolbarItem(placement: .topBarTrailing) {
                    Button("Add Movie") {
                        isAddMoviePresented.toggle()
                    }
                    .sheet(isPresented: $isAddMoviePresented) {
                        NavigationStack {
                            AddNewMoviceScreen()
                        }
                    }
                }
            }
    }
}

Creating Data

The Add Movie screen uses the @Environment(\.modelContext) to insert new movies

struct AddNewMoviceScreen: View {
    @Environment(\.modelContext) private var modelContext
    @Environment(\.dismiss) private var dismiss
    
    @State var title = ""
    @State var year = ""
    
    var body: some View {
        Form {
            TextField("Title", text: $title)
            TextField("Year", text: $year)
        }
        .toolbar {
            ToolbarItem(placement: .topBarTrailing) {
                Button("Save") {
                    let movie = Movie(title: title, year: Int(year) ?? 0)
                    modelContext.insert(movie)
                    try? modelContext.save()
                    dismiss()
                }
                .disabled(title.isEmpty || year.isEmpty)
            }
        }
    }
}

Updating Data

To edit existing movies, simply mutate the model and call save()

struct MovieDetailScreen: View {
    @Environment(\.modelContext) private var context
    let movie: Movie
    
    @State private var title = ""
    @State private var year: Int?
    
    var body: some View {
        Form {
            TextField("Title", text: $title)
            TextField("Year", value: $year, format: .number)
            Button("Update") {
                guard let year = year else { return }
                movie.title = title
                movie.year = year
                try? context.save()
            }
        }
        .onAppear {
            title = movie.title
            year = movie.year
        }
    }
}

Conclusion

SwiftData integrates seamlessly with SwiftUI, making persistent storage feel natural in declarative apps.
With just a few lines of code, we can have a fully persistent, reactive CRUD app ready.

Developers often receive reports from users or clients about random app crashes that cannot be reproduced in either App Store builds or local Xcode builds from our side. Diagnosing such elusive issues can be challenging, but there are several effective methods to identify and resolve them

In this blog, we’ll explore three approaches to investigating unknown crashes:

1. Xcode Organizer
2. Firebase Crashlytics
3. IPS Files from User Devices

Xcode Organizer

The Xcode Organizer is a built-in tool that allows you to review crash logs for apps associated with your Apple Developer account. Here’s how you can use it:

1. Open Xcode and go to the Window menu in the top menu bar.
2. Select Organizer.
3. In the Organizer, you’ll see all the apps tied to your Apple Developer account.
4. Select the specific app and version where the crashes were reported.
5. Review the crash logs listed. These logs include important details such as the crash type, stack trace, and affected devices.

The Xcode Organizer provides an excellent first step in analyzing crashes, as it centralizes reports from users who have opted into crash reporting via their devices.

Firebase Crashlytics

Firebase Crashlytics is another effective tool for diagnosing crashes, especially when you want real-time crash insights. It requires prior integration into your app, so ensure you’ve set it up during development.

How to Use Crashlytics to Investigate Crashes:

1. Log in to your Firebase Console and navigate to the Crashlytics dashboard for your app.
2. Review the list of crashes, including detailed stack traces, device models, OS versions, and user events leading up to the crash.
3. Use filters to narrow down crashes by app version, severity, or frequency.
4. Look for trends or patterns (e.g., a specific device or iOS version).

Crashlytics often provides breadcrumbs — logs of user interactions and app lifecycle events before the crash — making it easier to understand what might have gone wrong.

IPS Files from User Devices

When a crash occurs, the user’s device generates an Incident Processor Service (IPS) file, which contains detailed information about the crash. If a user reports a crash, you can guide them to retrieve the file and share it with you.

Steps to Retrieve an IPS File:

1. Navigate to Settings > Privacy & Security > Analytics & Improvements > Analytics Data on the user’s device.
2. Find the relevant crash report file (it will have a .ips extension and the app's name in the file name).
3. Share the file to developers.

How to Analyze the IPS File:

1. Open the IPS file in Xcode or any text editor.
2. Look for key sections such as the Exception Type, Thread State, and stack traces to identify the root cause.
3. Use the symbolicatecrash tool in Xcode to decode symbols for better readability if the file includes memory addresses instead of function names.

Conclusion

Diagnosing unknown app crashes can be challenging, but with tools like Xcode Organizer, Firebase Crashlytics, and IPS files, you can gain valuable insights to resolve these issues effectively. Each method offers unique advantages:

• Xcode Organizer is great for centralized crash reporting directly tied to your Apple Developer account.
• Firebase Crashlytics provides real-time insights with additional contextual data about crashes.
• IPS Files from user devices allow detailed offline analysis for crashes not captured by other tools.

By combining these approaches, you can systematically address even the most elusive crashes, improving your app’s stability and user experience.

Swift’s concurrency model has evolved significantly with the introduction of async/await. This modern approach simplifies writing asynchronous code, making it more readable and maintainable. In this blog post, we'll dive into the key concepts of Swift's async/await, exploring how to leverage them effectively in your code.

1. async

The async keyword marks a function as asynchronous, indicating that it may pause its execution to wait for a result. This is the foundation of Swift's concurrency model, enabling you to write non-blocking code.

func fetchData() async -> Data {
    // Simulate network request
    return Data()
}

2. await

The await keyword is used to pause the execution of an async function until the asynchronous task completes. It ensures that the code following it won't run until the awaited task finishes.

let data = await fetchData()

3. async throws

When a function can throw an error and is asynchronous, it is marked with async throws. This combination allows you to handle potential errors using try await.

func fetchData() async throws -> Data {
    guard let data = try? Data(contentsOf: URL(string: "https://example.com")!) else {
        throw URLError(.badURL)
    }
    return data
}

4. try await

When calling an async throws function, use try await to handle errors and wait for the result. This ensures that any errors are properly caught while waiting for the asynchronous task to complete.

do {
    let data = try await fetchData()
} catch {
    print("Failed to fetch data: \(error)")
}

5. Task {}

The Task {} initializer creates a new concurrent task, allowing you to execute asynchronous code in a structured way. This is useful for running async code outside of an async function.

Task {
    let data = await fetchData()
    print("Data fetched: \(data)")
}

6. async {}

Using async {} within a Task allows for parallel execution of multiple asynchronous tasks. This approach is helpful when you need to perform several async operations concurrently.

Task {
    async {
        let data1 = await fetchData()
        print("Data 1 fetched: \(data1)")
    }
    async {
        let data2 = await fetchData()
        print("Data 2 fetched: \(data2)")
    }
}

7. async let

The async let keyword allows you to start an asynchronous operation and await its result later. This is especially useful for running multiple async tasks in parallel, improving performance by not waiting for each task sequentially.

async let data1 = fetchData()
async let data2 = fetchData()

let results = await (data1, data2)
print("Data fetched: \(results)")

8. Continuation

Continuation is a powerful feature that bridges the gap between old completion handler-based APIs and the new async/await model. It allows you to convert callback-based code into an async function.

func fetchData() async -> Data {
    await withCheckedContinuation { continuation in
        // Simulate network request
        DispatchQueue.global().async {
            continuation.resume(returning: Data())
        }
    }
}

9. withThrowingTaskGroup

The withThrowingTaskGroup function lets you create a group of related tasks that can throw errors. You can await the completion of all tasks in the group or handle each result as it becomes available.

func fetchAllData() async throws -> [Data] {
    try await withThrowingTaskGroup(of: Data.self) { group in
        var results: [Data] = []
        
        for url in urls {
            group.addTask {
                try await fetchData(from: url)
            }
        }
        
        for try await data in group {
            results.append(data)
        }
        
        return results
    }
}

10. Task.cancel

The Task.cancel method allows you to cancel a running task, preventing it from completing its work. This is useful for handling scenarios where an async operation is no longer needed.

let task = Task {
    let data = await fetchData()
    print("Data fetched: \(data)")
}

// Cancel the task before it completes
task.cancel()

Conclusion

Swift’s async/await model simplifies the complexity of asynchronous programming, making your code more readable and easier to maintain. By mastering the concepts outlined in this guide, you’ll be well-equipped to handle concurrency in Swift effectively. Whether you’re migrating from completion handlers or starting fresh, async/await is a powerful tool that enhances Swift’s capabilities in handling asynchronous tasks.

Here we are going to learn about Protocols and how to use them in your iOS projects.

Protocols:

A protocols defines the blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. The protocols can then be adopted by a class, structure, or enumeration to provide an actual implementation of those requirements.

In addition to specifying requirements that conforming types must implement, you can extend a protocol to implement some of these requirements or to implement additional functionality that conforming types can take advantage of.

Syntax of a Protocols:

protocol SampleProtocol {
  // we can add here variable and methods without implementation
}

we can create protocol similar class, enum and struct. After created protocol we can inherit our required class or enum or struct like below.

//class
class SampleClass: SampleProtocol {
}

//struct 
struct SampleStruct: SampleProtocol {
}

//enum 
enum SampleEnum: SampleProtocol {
}

also we can inherit multiple protocols one class are separated by commas.

class SampleClass: SampleProtocolOne, SampleProtocolTwo {
}

so basically, we can have a class, struct or enum to conform to a protocol having variables, methods and initializers. After conforming a protocol, you must implement everything defined in it or else it will give an error.

Simple Protocol:

protocol Country {
  var name: String { get }
  var code: String { get }
  func details()
}

When variables are declared inside a protocol they can either be set as ‘get’ or ‘get set’. ‘get’ lets you set the variable to be-a constant, variable, or a computed or read-only property.

‘get set’ limits the property, you cannot set it to a constant, and it cannot be a computed property.

Mutating protocol:

It’s sometimes necessary for a method to modify (or mutate) the instance it belongs to. For instance methods on value types (that is, structures and enumerations) you place the mutating keyword before a method’s func keyword to indicate that the method is allowed to modify the instance it belongs to and any properties of that instance.

protocol Switchable {
  mutating func switch()
}

If you implement the Switchable protocol for a structure or enumeration, that structure or enumeration can conform to the protocol by providing an implementation of the switch() method that is also marked as mutating.

enum OnOffSwitch: Switchable {
  case off, on
  mutating func switch() {
    switch self {
      case .off:
         self = .on
      case .on:
         self = .off
   }
  }
}

var lightSwitch = OnOffSwitch.off
lightSwitch.switch()

Delegation:

Delegation is a design pattern that enables a class or structure to hand off (or delegate) some of its responsibilities to an instance of another type. Delegation pattern can also be used as a callback kind of mechanism.

protocol SampleProtocol {
  func doSomeThing()
}

class SampleClassOne {
    var delegate: SampleProtocol?
    func doSomeThing() {
        delegate?.doSomeThing()
}}

class SampleClassTwo: SampleProtocol {
    func doSomeThing() {
         print("delegate called")
}}

var sampleOne = SampleClassOne()
var sampleTwo = SampleClassTwo()
sampleOne.delegate = sampleTwo
sampleOne.doSomeThing()

Protocol Extensions

Protocols can be extended to provide method and property implementations to conforming types. This allows you to define behavior on protocols themselves, rather than in each type’s individual conformance or in a global function.

protocol SwitchableProtocol {
    var switchState: Bool { get }
}

extension SwitchableProtocol {
   var switchState: Bool { return true}
}

Protocol extension can be used for providing default implementation within the protocol itself as explained in the previous section.

Also If a conforming type provides its own implementation of a required method or property, that implementation will be used instead of the one provided by the extension.

I hope this article provides a little bit clear overview of the swift Protocols. reference from apple developer docs and other blogs.

This blog we are going to explore brief introduction to a Test Driven Development in iOS app development and will create a very basic unit test for Registration model struct.

For example we need to follow the Test Driven Development approach to implement the basic from validation logic. We will need to implement a class or struct to hold the provided user details and implement basic validation logic to make sure that the details valid or not.

Test-Driven Development

Test-Driven Development is a way of structuring our development process. if we not following the Test-Driven Development approach we will start write code first, after will start unit testing. In the test-driven development, we need to write a unit test first and then we can start to write app code to make the test case pass.

When we following Test-Driven development process for write a code, we need to follow 4 important steps that define the TDD life cycle: Red, Green, Refactor, Repeat. now we can explore about above mentioned four steps.

1. Red

In TDD process very initial step is red. It is called red is because the color of a failed unit test color code in Xcode is red. At this step before write app code, we need to create unit test case. That case will fail because we don’t have any app code. Once we have a failing unit test, the next step will be to write an app code for make this teat pass.

2. Green

The TDD life cycle next step is called Green. It is called Green because the color of passing unit test in Xcode is Green. This step we need to write a app code, to make our earlier written and failing unit test pass. Once unit test will pass the failing test color will change red to green.

3. Refactor

This step is called Refactor because at this step we need to clean up both our Unit test and app code for look and work good. Also we need to change constant to reusable methods. also need to avoid boiler plate code.

4.Repeat

The final step in the Test-Driven Development life cycle is called repeat. This means that we need to pick up a new feature and implement it by repeating the previous three steps. First we need to write failing unit test, then need to write app code to make unit test green, then we need to improve our unit test code and app code.

let’s have at very simple example of unit test that validates registration form data.

Create sample Xcode Project

We will start created very simple basic sample sample Xcode project. but one think we need to enable while creating project: we need to make sure that Unit testing is enabled for our project.

if you are not enable unit test checkbox or already have existing project with no unit tests, we can always create a new unit test target and unit test class from Xcode navigator.

1. First Switch to Test Navigator
2. Create a new unit test target and unit test class

We will give new Unit Test class a Name is UserFormModelTests.

Once we have a new unit test class created it will have some basic setup override methods from XCTestCase. The two important methods are setUp() method and the tearDown() method. other default methods we will delete. Once we delete that methods the test class will look like below image.

Now we can start to follow Test-Driven Development life cycle:-

first we need to create failing test method. Also, it is a good practices to write a minimum amount of code. Just enough for a test method to fail.

note that the name of the test method always must need to start with a test prefix. testUserFormModel_canCreateInstance().

if we run this test method it will fail because we don’t have UserFormModel. We completed TDD first step.

Now we can move second step in TDD life cycle Green. in Green need to start write app code and need to make fail test to pass. So we will create UserFormModel struct in our project.

import Foundation

struct UserFormModel {

   let firstName: String
   let lastName: String
   let email: String
}

if we try to run our test case. it will pass.

Now we can move third and fourth steps

At third step is Refactor. Above example code nothing is very important that i see improve in. this methods at this moment. So we will move next step.

The next step is to pick up the next functionality that makes sense to work on and repeat the 3 steps again.

Added some more test methods:

func testUserFormModel_ShouldPassIfValidateFirstName() {

      let unserModel = UserFormModel(firstName: "Raj",

                       lastName: "Mari",

                       email: "xx@gmail.com")

     XCTAssertTrue(unserModel.isValidFirstName())

}

func testUserFormModel_ShouldPassIfValidateLastName() {

      let unserModel = UserFormModel(firstName: "Raj",

                      lastName: "Mari",

                      email: "xx@gmail.com")

      XCTAssertTrue(unserModel.isValidLastName())

}

func testUserFormModel_ShouldPassIfValidateEmail() {

    let unserModel = UserFormModel(firstName: "Raj",

                     lastName: "Mari",

                     email: "xx@gmail.com")

   XCTAssertTrue(unserModel.isValidEmail())

}

func testUserFormModel_ShouldPassIfNotValidateEmail() {

      let unserModel = UserFormModel(firstName: "Raj",

                      lastName: "Mari",

                       email: "xxxxxx")

       XCTAssertFalse(unserModel.isValidEmail())

}

UserFormModel.swift

extension UserFormModel {

   func isValidFirstName() -> Bool {

        return firstName.count > 1

   }

   func isValidLastName() -> Bool {

       return firstName.count > 1

   }

   func isValidEmail() -> Bool {

         let emailRegEx = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}"

         let emailPred = NSPredicate(format:"SELF MATCHES %@", emailRegEx)

         return emailPred.evaluate(with: email)

 }

}

I hope this article provides a little bit clear overview of the Unit Testing in iOS. I will share soon this sample project in github here. Thanks

In this Android Fragments with Java tutorial we will learn the fundamental concepts of fragments while creating an app that displays list and details based on destination device.

Fragments:

A Fragment represents a behaviour or a portion of user interface in a FragmentActivity. we can combine multiple fragments in single activity. Also we can build a multi-pane UI and reuse same fragment in multiple activities. This fragment having own lifecycle, receive its own input events, and which we can add or remove while the activity is running.

A fragment must always be hosted in an activity and the fragment’s lifecycle is directly affected by the host activity’s lifecycle. For example, when the activity is paused the fragments also in pause state, and when activity is destroyed the all fragment are destroyed. While an activity is running, we can manipulate each fragment independently, such as add or remove them. Also when we perform fragment transaction we can also add it to a back stack that will be managed by activity. it will help us for back button press(navigate to previous fragment). if not required navigation for fragment we can ignore back stack.

Fragment life cycle:

Like an activity, a fragment has a lifecycle with events that occur when the fragment’s status changes. For instance, an event happens when the fragment becomes visible and active, or when the fragment becomes unused and is removed. You can also add code and behaviours to callbacks for these events as you would for an activity.

The following lifecycle events come into play when you add a fragment:

• onAttach: The fragment attaches to its host activity.
• onCreate: A new fragment instance initialises, which always happens after it attaches to the host.
• onCreateView: A fragment creates its portion of the view hierarchy, which is added to its activity’s view hierarchy.
• onActivityCreated: The fragment’s activity has finished its own onCreate event.
• onStart: The fragment is visible.
• onResume: The fragment is visible and intractable.
• onPause: The fragment is no longer intractable. This occurs when either the fragment is about to be removed or replaced or when the fragment’s activity pauses.
• onStop: The fragment is no longer visible. This occurs either after the fragment is about to be removed or replaced or when the fragment’s activity stops.
• onDestroyView: The view and related resources created in onCreateView are removed from the activity’s view hierarchy and destroyed.
• onDestroy: The fragment does its final clean up.
• onDetach: The fragment is detached from its activity.

Sample:

here’s an example of an activity using two fragments to create a two-pane layout. The activity below includes one fragment to show a list of Shakespeare play titles and another to show a summary of the play when selected from the list. It also demonstrates how to provide different configurations of the fragments, based on the screen configuration.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="horizontal">

    <FrameLayout
        android:id="@+id/frame"
        android:layout_width="0px"
        android:layout_height="match_parent"
        android:layout_weight="1" />

    <FrameLayout
        android:id="@+id/details"
        android:layout_width="0px"
        android:layout_height="match_parent"
        android:layout_weight="1"
        android:background="?android:attr/detailsElementBackground" />
</LinearLayout>

Using this layout, the system instantiates the TitlesFragment (which lists the play titles) as soon as the activity loads the layout, while the FrameLayout (where the fragment for showing the play summary appears) consumes space on the right side of the screen, but remains empty at first. As you'll see below, it's not until the user selects an item from the list that a fragment is placed into the FrameLayout.

However, not all screen configurations are wide enough to show both the list of plays and the summary, side by side. So, the layout above is used only for the landscape screen configuration, by saving it at res/layout-land/fragment_layout.xml.

Thus, when the screen is in portrait orientation, the system applies the following layout, which is saved at res/layout/fragment_layout.xml:

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:id="@+id/frame">

</FrameLayout>

So above we completed layout design part both landscape and normal screens. now we can move to implement activity and fragments.

First we can create ManiActivity.java file

when initial we come to this activity we are adding title fragment also if we rotate device we will get notification in onConfigurationChanged callback method.

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    setContentView(R.layout.fragment_layout);

    TitlesFragment fragment = new TitlesFragment();
    getSupportFragmentManager().beginTransaction()
            .replace(R.id.frame, fragment)
            .commit();
}

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);
    setContentView(R.layout.fragment_layout);
    TitlesFragment fragment = new TitlesFragment();
    getSupportFragmentManager().beginTransaction()
            .replace(R.id.frame, fragment)
            .commit();
}

Next, we can see how this is accomplished in the fragment classes. First is TitlesFragment, which shows the list of Shakespeare play titles. This fragment extends ListFragment and relies on it to handle most of the list view work.

public class TitlesFragment extends ListFragment {
    boolean mDualPane;
    int mCurCheckPosition = 0;

    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);

        setListAdapter(new ArrayAdapter<String>(getActivity(),
                android.R.layout.simple_list_item_activated_1, Shakespeare.TITLES));

        View detailsFrame = getActivity().findViewById(R.id.details);
        mDualPane = detailsFrame != null && detailsFrame.getVisibility() == View.VISIBLE;

        if (savedInstanceState != null) {
            mCurCheckPosition = savedInstanceState.getInt("curChoice", 0);
        }

        if (mDualPane) {
            getListView().setChoiceMode(ListView.CHOICE_MODE_SINGLE);
            showDetails(mCurCheckPosition);
        }
    }

    @Override
    public void onSaveInstanceState(Bundle outState) {
        super.onSaveInstanceState(outState);
        outState.putInt("curChoice", mCurCheckPosition);
    }

    @Override
    public void onListItemClick(ListView l, View v, int position, long id) {
        showDetails(position);
    }

    void showDetails(int index) {
        mCurCheckPosition = index;

        if (mDualPane) {
            getListView().setItemChecked(index, true);

            DetailsFragment details = (DetailsFragment)
                    getFragmentManager().findFragmentById(R.id.details);
            if (details == null || details.getShownIndex() != index) {
                details = DetailsFragment.newInstance(index);

                FragmentTransaction ft = getFragmentManager().beginTransaction();
                if (index == 0) {
                    ft.replace(R.id.details, details);
                } else {
                    ft.replace(R.id.details, details);
                }
                ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                ft.commit();
            }

        } else {
            Intent intent = new Intent();
            intent.setClass(getActivity(), DetailsActivity.class);
            intent.putExtra("index", index);
            startActivity(intent);
        }
    }
}

The second fragment, DetailsFragment shows the play summary for the item selected from the list from TitlesFragment:

public class DetailsFragment extends Fragment {

    public static DetailsFragment newInstance(int index) {
        DetailsFragment f = new DetailsFragment();

        Bundle args = new Bundle();
        args.putInt("index", index);
        f.setArguments(args);

        return f;
    }

    public int getShownIndex() {
        return getArguments().getInt("index", 0);
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                             Bundle savedInstanceState) {
        if (container == null) {
            return null;
        }

        ScrollView scroller = new ScrollView(getActivity());
        TextView text = new TextView(getActivity());
        int padding = (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP,
                4, getActivity().getResources().getDisplayMetrics());
        text.setPadding(padding, padding, padding, padding);
        scroller.addView(text);
        text.setText(Shakespeare.DIALOGUE[getShownIndex()]);
        return scroller;
    }
}

Recall from the TitlesFragment class, that, if the user clicks a list item and the current layout does not include the R.id.details view (which is where the DetailsFragment belongs), then the application starts the DetailsActivity activity to display the content of the item.

Here is the DetailsActivity, which simply embeds the DetailsFragment to display the selected play summary when the screen is in portrait orientation:

public class DetailsActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        if (getResources().getConfiguration().orientation
                == Configuration.ORIENTATION_LANDSCAPE) {
            finish();
            return;
        }

        if (savedInstanceState == null) {
            DetailsFragment details = new DetailsFragment();
            details.setArguments(getIntent().getExtras());
            getSupportFragmentManager().beginTransaction().add(android.R.id.content, details).commit();
        }
    }
}

Notice that this activity finishes itself if the configuration is landscape, so that the main activity can take over and display the DetailsFragment alongside the TitlesFragment. This can happen if the user begins the DetailsActivity while in portrait orientation, but then rotates to landscape (which restarts the current activity).

I hope this article provides a little bit clear overview of the Android Fragments. Download this sample project here. Thanks

if let is also one type of optional binding. Use optional binding to find out whether an optional contains a value, and if so, to make that value available as a temporary constant or variable

An optional binding for the if statement is as follows −

if let value = optionalValue {
// use value
} else {
if optionalValue nil we can handle here
}

Use if let for small number of variables unwrapping and value of unwrapped variable not required outside block scope.

Also instead of if let we can use if var also. if any case need to change value within a branching scope we can use if var.

When we need to continue execution in the current enclosing scope if value is nil or other.

if any scope need to check multiple values same time it is having more boiler code like below

if let name = userName {
if let password = userPassword {
// use name and password
} else {
// invalid password
}} else {
// invalid userName
}

guard let:

The guard let statement, on the other hand, makes our code more readable and we can avoid boiler code. Readability and easy maintenance are extremely important, especially when working with other programmers. The guard let statement help us to avoid the complexity of numerous nested conditions as seen in the if let example above. Different from the if let, the guard let statement makes early exits possible with an emphasis on negative cases with errors rather than on positive cases. This means we can test negative cases earlier by running the guard’s else statement if the condition is NOT met, rather than wait for nested conditions to pass first.

Also we can avoid nested if let like below

let name: String? = “raj”

let password: String? = “password”

func test () {

guard let userName = name, let userPassword = password else {

print(“failed validation”)

return

}

}

One thing to note: each guard statement must always transfer control by exiting the scope it is in. More specifically, if the “guard” is used in functions, it would usually return, and in loops, it would break or continue.

Defer Statement:

You use a defer statement to execute a set of statements just before code execution leaves the current block of code. This statement lets you do any necessary cleanup that should be performed regardless of how execution leaves the current block of code—whether it leaves because an error was thrown or because of a statement such as return or break. For example, you can use a defer statement to ensure that file descriptors are closed and manually allocated memory is freed.

A defer statement defers execution until the current scope is exited. This statement consists of the defer keyword and the statements to be executed later.

I hope you get little bit idea about above three topics. Thanks for reading.

In Swift we have few different options available for asynchronous programming. Now we are going to discuss about GCD. GCD also on of the leading asynchronous topic in swift iOS. GCD provides and manages FIFO queues to which your application can submit tasks in the form of block objects. Work submitted to dispatch queues are executed on a pool of threads fully managed by the system. No guarantee is made as to the thread on which a task executes.

Also GCD is an API provided by apple to allow you to manage concurrent operations in a smooth way multi tasking, in order to avoid stuck of your application and keep it always intractable for users. GCD having three different type of Queues like as

1. The Main Queue
2. The Global Queue
3. Custom Queues

The Main Queue:

We should not able perform UI related operations on a background queue or queue other than the main queue, the compiler will show a warning if we do so. We need the main queue to perform UI operations. We can use the main queue like below

DispatchQueue.main.async {
   self.view.backgroundColor = UIColor.blue
  }

The Global Queue:

This Queue is separated into 5 main types and a default type according to QoS(Quality of Service), from highest priority to lowest. QoS is an enum with specific cases, and by providing the proper QoS value upon the queue initialisation you specify the desired priority. If no QoS is defined, then a default priority is given by to the queue. The following list summarises the available QoS cases, also called QoS classes. The first class means the highest priority, the last one the lowest priority:

• userInteractive
• userInitiated
• default
• utility
• background
• unspecified

1- userInteractive : Work is virtually instantaneous. Similar to main thread.
2- userInitiated : Work is nearly instantaneous, such as a few seconds or less.
3- default: don’t use it usually , the type will be inferred by the system
4- utility: Work takes a few seconds to a few minutes.
5- background: Work takes significant time, such as minutes or hours.

Both, utility and background threads should be used for heavy operations that needs time in order not to block the main thread. hsdhs sudfsidfh usfsaifh usdfiasfhisa diusadfisa iasidasidhgdwidiaw udaidhoasdoas dusaifdhoashd aiufai
You can simply call one as follows:

DispatchQueue.global(qos: .background).async {
    //do background thread here
}

above way we can achieve other QoS also.

Custom Queues:

Custom queues are queues that you can create on your own and give whatever QOS and attributes you want

let concurrentQueue = DispatchQueue(label: “concurrentQueue”, qos: .background, attributes: .concurrent)

let serialQueue = DispatchQueue(label: “serialQueue”, qos: .background)

also we can able to use same time combined Queues like below while downloading image from URL.

DispatchQueue.global(qos: .background).async {
     let image = downloadImage()

DispatchQueue.main.async {
    self.imageView.image = image
}
}

func downloadImage() -> UIImage {
//download image here
return image
}

As you can notice we do the heavy operation that can take a lot of time inside a background thread and then display the image inside an imageView using the main thread.

Async VS Sync:

As you saw in the example above we used the word async after each queue.
With GCD, you can dispatch a task either synchronously or asynchronously.
Sync means that no other task will start until the sync operation finishes , while Async will allow other tasks to start even if it didn’t finish yet.

Let us take a look at real world examples:

Conclusion:

GCD is the simplest way to write a multitasking code on iOS. We can use this to move the heavy tasks on the background thread and reduce the load on the main thread. There are lots of topics to explore in GCD. I haven’t covered them all to keep this post simple and short but covered all the essentials have been covered.

Now a day all application having Biometric Authentication. Because FaceID and TouchID can be used for apps to authenticate users information like login credential, in-app purchase and sharing information one to another applications. Also in Mobile security is playing very major and crucial role last couple of years. Many platforms are allowing device owners to verify their identity by TouchID, FaceID and voice recognition. So apple also improving their local authentication TouchID and FaceID. Here we are going to explore how to add FaceID and TouchID in our iOS applications.

First I am going to create simple application and will navigate to ViewController. Then need to import LocalAuthentication into our ViewController. This LocalAuthentication framework will give all access for TouchID and FaceID validation in our local application. After we need to create LAContext object it will give us UI for evaluating the authentication policies and access controls, managing credentials, and invalidating authentication contexts.

let localAuthenticationContext = LAContext()
localAuthenticationContext.localizedFallbackTitle = "Use Passcode"

After creation of LAContext object we need to check policy. This LAPolicy having two types,

• deviceOwnerAuthenticationWithBiometrics: It puts restriction to use only biometric authentication to authenticate the device owner.
• deviceOwnerAuthentication: It will allow the application to authenticate the device owner using biometric or the device password.

Here we are going to use deviceOwnerAuthenticationWithBiometrics. This will allow users to fallback to any other authentication method implemented by developers like username and pin code etc.

if localAuthenticationContext.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &authError) { 

}

canEvalutePolicy is Boolean method it will return true or false. if user not enrolled TouchID or FaceID it will return false. So we can show some alert to users. If it is true we need to call evalutePolicy.

localAuthenticationContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, localizedReason: reasonString) { success, evaluateError in
if success {

} else {
guard let error = evaluateError else {
return
}

print(self.evaluateAuthenticationPolicyMessageForLA(errorCode: error._code))
}
}

if we call evalutePolicy method it will requests authentication from users with specified security policy and it will show authentication dialog contains a cancel button with default title. and one more before implementing authentication we need to add usage description in info.plist file.

<key>NSFaceIDUsageDescription</key>

<string>Logging in with Face ID</string>

evalutePolicy: asynchronously evaluates an authentication policy

reasonString:- this is the reason for requesting authentication, which will be displayed to the user

reply:- this is closure executed when evaluation finishes, which gives back success/failure and error if any with Error code

If evaluation success one can proceed with your further process, if not you can alt the user as he is unAuthorised.

I hope this article provides a little bit clear overview of the Add Authentication and As soon as possible i will share my code in GitHub. please check my GitHub repositories.

Introduction

We have many libraries that support displaying charts and one of them is Charts library and here i am going to use this library. Now we can open Xcode and create ChartsDemo Xcode project. After create project we need to add dependency library, we can add different ways like manual download, pod install and Carthage. Here I am going to use Pod installation. So we need to create pod file for pod install. we can use following command for pod file create pod init. pod file has created after this we can view pod file using following command vi Podfile. now we can add pod Charts in Podfile. after add this pod we can install. after installation done need to open ChartsDemo.xcworkspace. After open project add four ViewController like below image.

First we can add three different button in HomeViewController and add each button segue show for different storyboard reference like below.

Then run our application and test navigation it is working as per our requirement. if it works well we can start design chart design. First i am going to start BarChart design.

BarChart

Open BarChartStoryboard user interface then add View object to our storyboard. after adding view don’t forget to add auto layout constraint. and add custom BarChartView class as well.

After that, we need to drag an IBOutlet connection from the View on the screen to the BarChartViewController that manages the BarChartView. Keep in mind to import the Charts library in order for the code to compile successfully. I have build our application it is working as per our need. Then we can create MockData class for chart. in MockData class i am going to add some cricket player list with them random hundreds list like below.

let players = [“K.S. Williamson”, “S.P.D. Smith”, “V. Kohli”, “Sachin”, “J.J. Bumrah”, “R.A. Jadeja”]
let hundreds = [6, 8, 26, 30, 8, 10]

Then, we are going to create a function displaying all these data and put it inside viewDidLoad() like this

barChartData(playerList: players, values: hundreds.map { Double($0) })

in viewDidLoad method inside setup our barChart animate, pinchZoomEnabled and etc.

barChartView.animate(yAxisDuration: 2.0)
barChartView.pinchZoomEnabled = false
barChartView.drawBarShadowEnabled = false
barChartView.drawBordersEnabled = false
barChartView.doubleTapToZoomEnabled = false
barChartView.drawGridBackgroundEnabled = true

after setup now we can move to show barChart setup inside barChartData(…) method.

barChartView.noDataText = “No Data available for Chart”
var dataEntries: [BarChartDataEntry] = []

for i in 0..<playerList.count {
let dataEntry = BarChartDataEntry(x: Double(i), y: Double(values[i]))
dataEntries.append(dataEntry)
}

let chartDataSet = BarChartDataSet(entries: dataEntries, label: “Bar Chart View”)
let chartData = BarChartData(dataSet: chartDataSet)
barChartView.data = chartData

we done all setup now we can run our application. after run I can able to see our barChart.

Other charts as well same need to do first add View object in respective storyboard and add outlet for our ViewController, then get mock data and send that data to respective chart setups.

LineChart

var dataEntries: [ChartDataEntry] = []
for i in 0..<dataPoints.count-1 {
let dataEntry = ChartDataEntry(x: values[i], y: Double(i))
dataEntries.append(dataEntry)
}

let lineChartDataSet = LineChartDataSet(entries: dataEntries, label: nil)
let lineChartData = LineChartData(dataSet: lineChartDataSet)
lineChartView.data = lineChartData

PieChart

// 1. Set ChartDataEntry
var dataEntries: [ChartDataEntry] = []
for i in 0..<player.count {
let dataEntry = PieChartDataEntry(value: values[i], label: player[i], data: player[i] as AnyObject)
dataEntries.append(dataEntry)
}

// 2. Set ChartDataSet
let pieChartDataSet = PieChartDataSet(entries: dataEntries, label: nil)
pieChartDataSet.colors = colorsOfCharts(numbersOfColor: player.count)

// 3. Set ChartData
let pieChartData = PieChartData(dataSet: pieChartDataSet)
let format = NumberFormatter()
format.numberStyle = .none
let formatter = DefaultValueFormatter(formatter: format)
pieChartData.setValueFormatter(formatter)

// 4. Assign it to the chart’s data
pieChartView.data = pieChartData

1. For each player and the hundreds he has, we set it to PieChartDataEntry object — a subclass of ChartDataEntry. Then we save it inside an array of PieChartDataEntry type.
2. The PieChartDataSet — a subclass of ChartDataSet will use this array to custom how to display them on the screen. For example, this line of codepieChartDataSet.colors will set colors for each part.
3. The PieChartData — a subclass of ChartData will store the PieChartDataSet. At this point, you can change the format of values which will be shown on the screen such as 15 instead of 15.0.
4. After we have done setting up everything, we assign the pieChartData to pieChartView.data
5. then we need to select some random colour for each players.

for _ in 0..<numbersOfColor {
   let red = Double(arc4random_uniform(256))
   let green = Double(arc4random_uniform(256))
   let blue = Double(arc4random_uniform(256))
   let color = UIColor(red: CGFloat(red/255), green:   CGFloat(green/255), blue: CGFloat(blue/255), alpha: 1)
   colors.append(color)
}

after finish coding part we can run our application we can see our pie charts.

Conclusion

I hope this article provides a little bit clear overview of the iOS Charts. I think here after we can able easily make beautiful and attractive charts using Charts dependency. As soon as possible i will share my code in GitHub. please check my GitHub repositories.