Sarguru Subramanian

Sarkur Subramanian, currently working in Publicis's APINTA as a lead experience engineer. I have an experience of 14 years in the mobile domain, specifically in native Android and Flutter. I also have experience in React Native. I did my master's in media informatics in Germany at RWTH Aachen University, and then completed my bachelor's in information technology. So, I have a total of 14 plus 7 years of experience. I have been specifically in mobile for 13 years nearly. And earlier, I started my career in a two-year stint at Quattro Engineering Industries Limited in Coimbatore, then at HCL Technologies as a lead engineer, and I continued there in the Android domain. Then I moved to Photon Infotech as a senior program manager, and I also made my career in native Android. In 2016, I came to Publicis Sapient. I joined here as a senior mobile developer, and for my McDonald's projects, I continued my career in native Android. I then learned Flutter and added new features. I continued my career in Flutter. I also did many projects in Flutter for Deepak Centimeters commercial projects, and for Omenthal Telecom communication side.

When building a secure mobile application that interacts with multiple external services, several design and architecture considerations are important. Specifically, I implement a layered architecture with a well-defined architecture pattern. There's a move to MVVM. Earlier, I started with MVC, but I found it more suitable to use MVVM to separate concerns and isolate security-sensitive components of the user interface elements. I also utilize HTTPS for all communication between the mobile application and external services to encrypt the data transmission and prevent interceptions. I implement a robust authentication method, such as 2FA, and employ encryption technologies. By incorporating these architecture considerations into the design and development process, it can help mitigate security risks and ensure the confidentiality, integrity, and availability of data. Apart from data encryption, secure data storage is also crucial for storing sensitive information like user credentials and authentication tokens. I also validate and sanitize all user input to prevent security vulnerabilities like SQL injections. We can implement security APIs on the server side to interact with external services securely. We can also utilize API gateways, firewalls, and intrusion detection systems to monitor and protect against malicious attacks. Secure session management techniques can be used to maintain user sessions securely and prevent hijacking and fixation attacks. Following secure coding practices and guidelines can help mitigate common security threats, such as code injection or insecure deserialization. Regular security audits and penetration testing can also help identify and remediate security vulnerabilities in the mobile application.

How would you handle versioning of a mobile app APH to support legacy, applications? Okay, so handling legacy applications requires careful planning and implementation to ensure backward compatibility while introducing new features and updates. So what is the thing we need to consider over here? We need to adopt a clear and consistent versioning scheme following semantic versioning principles, so that this allows the developer to understand the impact of version changes based on the significance of the updates. Also, we need to include the API version in the URL path to explicitly specify the version of the API being accessed. So this approach provides clear communication and ensures that the clients can continue to use the API if necessary also. So, alternatively, you can use a custom header or a query parameter to indicate the API version. This approach allows for more flexibility in managing the versioning, but requires additional handling on the client and server side. Then, while introducing the changes to the API, we can strive to maintain backward compatibility with older versions to ensure that existing clients can continue to function without requiring immediate updates. So this may involve duplicating old endpoints gradually rather than removing them abruptly. Right? So we need to establish a clear duplication policy for older API versions, including timelines for duplication in some. So that we can communicate these changes to developers and provide sufficient time for them to migrate to the newer versions. Then we can also maintain proper documentation that outlines the differences between API versions, including any deprecated features and migration guidelines for transitions from older versions to new ones. Then we can implement a mechanism for negotiation to allow clients to specify their preferred API versions dynamically. This can be achieved through content negotiation or by providing versioning information in response headers. Also, we can conduct a thorough web testing of the API version changes to identify potential compatibility issues and ensure seamless integration with legacy applications. So, probably, you can monitor the usage and performance to detect any anomalies or errors resulting from versioning changes. Then, we can implement a robust error handling mechanism to provide meaningful error messages and status codes when clients attempt to access a deprecated or unsupported API version. So this will help the user to understand the reason for the failure and take appropriate actions. So by following these things, it's a good practice for these things.

How do you integrate analytics into a Flutter mobile app for better user experience tracking? Integrating analytics into a Flutter mobile app is essential for tracking user behavior, monitoring app performance, or gaining insights to improve the overall user experience. One of the things is we need to choose a proper or reliable analytics service provider, like Google Analytics, or Firebase, or any other things or proper analytics service provider we need to choose it based on our requirements or budgets. Then, we need to add analytics SDK dependencies to the Flutter project by including the respective package into the pubspec.yaml file. We need to follow the installation instruction provided with analytics service provider to set up the SDK, and then initialize it in our Flutter applications. We need to initialize the analytics service within the appropriate configuration settings, including the API keys or tracking IDs or other parameters required to establish a connection with the analytics server. We need to implement event tracking to monitor user interactions as button clicks or form submissions, or take views or custom events relevant to the application functionality. We can use the analytics service to track these events and associate them with the specific user actions. Then, we need to capture user attributes and properties to segment and analyze user behavior based upon the preferences, device, or characteristics, and other relevant metrics. We can utilize the user identification methods to track user sessions and behaviors across multiple sessions and devices. Then, we need to define custom events and parameters to track specific actions or scenarios unique to the application features and user flow. We can customize the events categories and attributes to align with the analytics goals and reporting requirements. Also, we can implement errors and exception tracking to capture and report runtime errors, crashes, or unexpected behaviors occurring within the app. We can monitor error logs and stack traces to identify the unresolved issues. We can integrate performance monitoring tools provided by analytics services to measure the performance metrics, like startup time, screen rendering speed, and network latency. We need to ensure data privacy regulations by obtaining user consent for data collection and processing, and implement the mechanism to enable or disable analytics tracking if desired. We can access the analytics dashboard provided by the analytics service to visualize and analyze user engagement, retention, conversion rates, and other key performance indicators.

I choose specifically, the repository pattern combined with the observer pattern, can be a powerful choice for this case. The repository pattern usually abstracts the data access logic from the rest of the application, providing a centralized interface to interact with the data sources, such as a local database, remote APIs, or cloud tools. By encapsulating the data access logic within the repositories, we can easily switch between different data sources without affecting the higher-level application logic. At the same time, the observer pattern facilitates communication and synchronization between different components of the application by establishing a one-to-many relationship between the observers and the subjects. So when the state of the application and the state of the subject change, it notifies all registered observers, allowing them to react accordingly. Combining these patterns for data synchronization across multiple mobile platforms offers several benefits, including modularity, abstraction, platform independence, and centralized control, as well as asynchronous communication. By implementing the repository pattern along with the observer pattern for data synchronization across multiple mobile applications, we can achieve a flexible, scalable, and maintainable architecture that facilitates efficient data management and synchronization in the mobile app.

What is the best practice for implementing navigation within large-scale Flutter? Okay, so implementing the navigation requires a careful consideration to ensure a smooth and intuitive user experience. So, one of the things is the hierarchy structure is one of the things. We need to organize the navigation in a hierarchical manner, breaking down the larger-scale features into smaller logical sections or screens. This helps the user navigate through the feature more easily and understand the relationship between the different parts of the feature. And, also, we need to provide a clear and intuitive navigation that guides users through the features. So, we can use description labels, icons, and visual cues to indicate the purpose and destination of each navigation option. Then, we can use navigation drawers or tabs to display high-level navigation options for large-scale features. This will allow users to quickly switch between different sections or views. Currently, many projects are using the bottom navigation bar. Considering the use of this navigation bar, it will provide easy access to frequently used features or screens with large-scale features. The bottom navigation bar can display icons or labels for different sections of the features, allowing users to switch between them with a single tap. We can also use deep linking to implement the deep link tool, which will allow the user to navigate directly to the specific screen or content within the large-scale feature from external sources. Then, we can use breadcrumb navigation to display the user's current location within the large-scale feature and provide a path for navigating back to previous screens or sections. Additionally, we can implement search functionality within the large-scale feature to help users quickly find specific information, and we can go to that specific page by filtering it out on suggestion strings. Then, we can employ progressive disclosure to reveal additional navigation options.

I have a class of my custom widget, which is a stateful widget, and you're overriding my custom widget's state with the created state. That's fine. Then, you have a class that extends the state of my custom widget. Okay? Then you have a stream subscription variable. In the init state, I am creating a stream variable, which has a stream.periodic for a duration of one second. Then there's a subscription variable, which is equal to the stream variable's listen of data, and you are performing actions with the data. And inside the dispose method, you are doing what I left out, and you are just disposing of the stream. Okay. The issue is with the description of the stream within the widget method and the lack of disposing of that stream's subscription in the dispose method. This is the one I mainly think of. So, actually, there was no explicit disposal of that stream subscription method. So this could lead to memory leaks and unexpected behavior if the test stream subscription is not cancelled when the widget is removed. Therefore, the dispose method should ensure that the stream subscription is properly disposed of by calling the cancel method on the stream subscription. This ensures that the resources associated with the stream subscriptions are released when the widget is no longer in use.

Examine the code block for a API call in Flutter. Is there a better way to handle the HTTP request and the response to improve error handling and maintainability? So in the future method, fetch user data, you that is an async method okay? You have a final response is equal to await the HTTP of some URL you have given? If the response's status code is 200, then you are decoding the JSON from the response body and assigning it to the user variable. Else you are throwing an exception, failing to load data. You want better handling for this case. I think the provided code actually needs improvement for error handling and maintainability only. The rest of it feels comfortable. Actually, here is the most robust approach using the HTTP package. So I believe it's out that we can handle response codes better, right? So, yes, we're okay. I think the fetch user data function, this async event, is used to handle the asynchronous operation more cleanly. This allows for more readable code compared to using callbacks directly. The Uri.parse method is used to pass the URL string. This ensures that the URL is properly formatted and avoids potential issues with special characters or spaces in the URL. Instead of directly throwing an exception based on the HTTP response status codes, we can throw a generic exception with the description method. This makes error handling more consistent and easy to understand. The error message should include the HTTP status code or provide more context about the nature of the error. This can be helpful for debugging and troubleshooting the issues with the API call. So, if I say via code, you are having it out as a you're getting that value, right? That by the user. We should have it also as a future, user-specific user object has to be there. Then in the final, that is the response, you are awaiting on the cp dot get? That part is also why I'm finding it out okay. Instead of directly specifying it out, I mean, HTTP dot get, you can make it a dot pass of that URL. In case of a 200, that is the user data, you can directly get that value as a map value, like a string of map of string of dynamics. Those things are response data can be caught as a map of string or dynamics. By then, from the error throwing of error? I told it out that we can use a generic expression as stating over that response status code over there. That could be better.

Handling real-time data synchronization across multiple user devices in a Flutter application requires a well-thought-out strategy that addresses data consistency, scalability, performance, and user experience. Without hesitation, we need to select a real-time database or backend services that support real-time data synchronization and provide SDKs or APIs for Flutter implementation. Popular options include Firebase's real-time database, Firestore, GraphQL, subscriptions, and services like AWS AppSync. We can then design the data model and database schema to facilitate efficient real-time synchronization. Normalizing or denormalizing data, considering factors like query performance, data relationships, and update frequency, is crucial. We can use the real-time capabilities provided by the chosen database or backend services to subscribe to data change events. Implementing listeners or observers allows us to receive real-time updates whenever the data changes on the server. Additionally, we can implement offline support by using local storage mechanisms, such as a local database or a JSON file, to catch data locally and synchronize changes with other devices when back online. To handle conflicting changes from multiple devices, we can implement conflict resolution strategies. Minimizing data transferred between the client and server optimizes network bandwidth and improves performance. Techniques like delta updates, data compression, and batching requests reduce latency and improve responsiveness. We can implement secure authentication and authorization mechanisms using authenticated providers like Firebase authentication or OAuth 2.0 to control access to user data. Monitoring real-time synchronization performance using monitoring tools provided by the database or backend service is also essential. Implementing error handling and recovery mechanisms to handle cases like network disruptions, server outages, or client-side errors is vital. Providing information to error messages and retry mechanisms can help recover from transition errors. Finally, conducting thorough testing of real-time synchronization features under various scenarios is crucial to effectively implement real-time data synchronization across multiple user devices.

How would you integrate the Firebase backend with the React Native app for real-time database updated features? To make it clear, we need to create a Firebase project on the Firebase console. We need to add our React Native application to the Firebase project by registering in both Android and iOS apps. And, we need to download the respective configuration files. In Android, we will have the Google Services JSON file. In iOS, we will have the Google Services info.plist file. We will then install the Firebase SDK using npm install. We need to install the Firebase SDK specifically for our app. In the case of iOS, we need to do a pod install after installing the SDK. We then need to initialize the Firebase in our React Native application by importing the Firebase configuration and initializing the Firebase app. This typically involves creating a Firebase configuration file and importing it to the app's entry point. We need to use the Firebase real-time database to store and synchronize data in real time across our clients. We can use the Firebase listener to handle real-time updates or data in the database. We can subscribe to database references and listen to changes using listeners like on or once. If the application requires user authentication, we can integrate Firebase authentication to authenticate users using email or password also. We then need to thoroughly test the Firebase integration to ensure that the real-time updates and data synchronization are working as expected. We need to implement error handling and error recovery mechanisms to handle network actions and server errors. We can use Firebase error codes and exceptions to handle errors and provide meaningful feedbacks.

What are the key factors you consider when integrating third-party UI components into the Shopify mobile application? Okay, see, actually, We need to ensure that the third-party UI components are compatible with the Shopify application technology stack, including the programming language framework, such as React Native or Flutter, or platform requirements, like iOS or Android. We need to verify that the components integrate seamlessly with the existing codebase and architecture. Then we need to evaluate the security practices and data handling policies of the third-party components to ensure they meet industry standards and best practices for securing sensitive user data and transactions. Then we need to verify that the components do not introduce security vulnerabilities or privacy risks into the application. Then we need to assess the level of customization and theming available for the third-party component to align with the branding and design requirements of the Shopify application. So that's why we need to ensure the components support flexible styling and theming capabilities to maintain a consistent user experience across different screens and modules. So then we need to consider performance implications in terms of integrating the third-party UI components. We need to evaluate the performance characteristics of the components, including speed, rendering speed, memory usage, and network overhead to minimize the impact on app performance and responsiveness. We need to optimize the usage of third-party resources to ensure efficient resource utilization. We need to ensure that the documentation, code samples, tutorials, and community forums are available to assist developers in using and extending the components effectively. We need to verify that the third-party UI components are licensed properly and comply with relevant license agreements, open-source licenses, and intellectual property rights. They need to ensure the components comply with legal and regulatory requirements governing software distribution, usage, and within the application. Then we can consider the long-term scalability and maintainability of the third-party components within the application. We need to evaluate the provider's track record in delivering updates, bug fixes, new features, and their commitments to long-term support and compatibility. By carefully considering these factors, we can effectively integrate third-party UI components into the Shopify app.