The NeoRoo Synchronization Enhancement project aims to implement robust data synchronization between the mobile application and DHIS2 backend using the d2 library, ensuring seamless operation across both Android and iOS platforms. This project will improve data reliability, offline capabilities, and sync performance while maintaining consistency with the DHIS2 data model.
Core Objectives:
Data Synchronization Architecture
Implement d2 library integration
Create Flutter-native platform channels
Design offline-first data storage
Develop conflict resolution strategies
Implement real-time sync indicators
Cross-Platform Implementation
Flutter widget development
Platform-specific optimizations
Background sync services
Push notification integration
Battery optimization
Testing Infrastructure
Cross-platform test suites
Sync reliability metrics
Performance benchmarking
Edge case handling
Network condition simulation
The deliverables of the project are as follows:
Develop Flutter integration layer for d2 library
Create platform-specific native modules where needed
Implement comprehensive sync logic
Build automated testing infrastructure
Create monitoring and debugging tools
Provide documentation and deployment guides
This project will significantly improve the reliability and performance of data synchronization in the NeoRoo app while ensuring consistent behavior across both Android and iOS platforms. The integration of the d2 library will provide robust DHIS2 compatibility, while the Flutter implementation ensures a maintainable and efficient codebase.
This implementation will ensure that healthcare workers using NeoRoo can reliably sync their data regardless of network conditions or platform choice, improving the overall effectiveness of the application in supporting neonatal care.
Hello,
I’m interested in contributing to NeoRoo for this year’s GSoC. I’ve started exploring the source code and documentation and wanted to ask if there are any recommended starting points or good first issues?
Hello @sunbiz , I know this thread isn’t directly related, but since you’re also the maintainer of lh-toolkit-cost-of-care-app — I wanted to ask here directly.
I’m interested in working on that project and have been developing a proposal around modernizing the app and adding features like voice search, voice input, and AI-assisted cost explanation for rural Community Health Workers. I’ve also opened a separate thread for it here.
My main question is — would contributions to that project and a proposal based on it be considered for GSoC 2026? I don’t want to mess up without some guidance first!
I’ve been researching the architecture for this project’s proposal and wanted to get your thoughts on a platform-specific hurdle.
We have to use platform channels to integrate the native DHIS2 Android SDK , as requested. However, since the d2 library doesn’t have a native iOS peer, I’m trying to figure out the best way to achieve the cross-platform requirement.
Would it be acceptable to handle iOS entirely in Dart? My idea is to rely on the Android SDK for Android devices via a MethodChannel, but for iOS, I’d build a custom sync layer using Hive (since it’s already in the dependencies) to queue events offline, and then push them via the DHIS2 REST API when connectivity is restored.
I would really appreciate your suggestion on this? Thanks in advance!
While exploring the NeoRoo codebase and the proposed d2-based synchronization approach, I noticed that the DHIS2 d2 SDK is designed primarily for Android.
Since NeoRoo is a Flutter application intended to run on both Android and iOS, I wanted to clarify how iOS support is expected to be handled as part of this project.
Would the goal be to integrate the Android d2 SDK via platform channels for Android while maintaining a different networking layer for iOS, or is there an alternative cross-platform approach planned for the synchronization layer?
I’m trying to better understand the expected architecture before drafting my proposal.
My name is Sonika Chowdary G, a second-year Computer Science undergraduate at BITS Pilani, India. I recently completed a 6-month backend development internship using Python and Django, working on backend systems and REST APIs. I am also familiar with the MERN stack and Flutter, and have experience building web and mobile applications.
While reviewing the proposed NeoRoo Synchronization Enhancement project, I noticed an architectural blocker regarding the iOS side of the implementation. The proposal needs clarification on the iOS synchronization approach (separate iOS layer, Flutter/Dart shared layer, or another cross-platform solution).
Apart from this , I am planning the project in the following way:
Define the synchronization scope clearly by identifying which NeoRoo data needs to be synced with DHIS2.
Map the data model properly, including which parts can remain TEI-based and which parts may need a more event-oriented/time-series structure.
Design an offline-first local storage layer with sync states, queue management, and retry handling.
Build the synchronization lifecycle, including push/pull flows, conflict resolution, and sync status tracking.
Integrate this flow into the Flutter app through repositories, BLoCs, and UI indicators.
Add testing, monitoring, and debugging support for reliability, network failure scenarios, and performance validation.
So at this point, my understanding is:
the iOS support question is a real blocker for final implementation planning around d2
but the broader synchronization architecture, data flow, offline strategy, and testing plan can still be designed in parallel
I wanted to highlight this explicitly before finalizing the implementation approach in the proposal.
Thanks !!
Hi @Hrishikesh-Bhagwat , @sunbiz it’s honestly quite nostalgic to see this project coming into GSoC 2026.
I still remember the conversations we had when this project was first introduced. We discussed how Kangaroo Mother Care data could be transmitted through a mobile app to a healthcare portal, and that really stuck with me. I’ve always wanted to contribute to the healthcare domain, and it feels like the perfect time to reconnect with this .
I might be a bit out of touch with where things stand now, but I’m genuinely excited to dive back in understand the current user experience, explore the logic and architecture, and see how everything has evolved.
I’d love the opportunity to contribute and be a part of this journey. Thanks!
Hey everyone, I’ve been working on my proposal for this project for a while now. I had opened some MRs almost 3 weeks ago, but they still haven’t been reviewed. Can I please know if they’d be accepted? Because I’m working on my proposal currently, and if they’re not merged I’m not being able to include them in my proposal…
Please, let me know , if it is going to be merged or closed. The deadline is approaching, so it would be really helpful..
I am currently architecting the Flutter-to-Native MethodChannels for my proposal. In the project description, it mentions “maintaining consistency with the DHIS2 data model.” I wanted to ask for a slight clarification on the preferred scope for this regarding the Flutter Dart models.
Right now, the Dart models (e.g., InfantModel.fromJson) are strictly structured to parse the legacy DHIS2 Web API JSON format (expecting specific attributes lists and string keys like "NeoRoo_Birth_Date"). However, the native d2 local SQLite database will return TrackedEntityInstance native Kotlin/Swift objects natively.
For the GSoC proposal, which approach do you think would be better?
Approach A : I build a “Translation Layer” natively in Kotlin/Swift that formats the local database output to mimic the legacy Web API JSON before sending it across the MethodChannel. By doing this,the migrations are strictly isolated to the Repository files and there’s need to rewrite the Models, BLoCs, or UI.
Approach B : We ditch the Web API format entirely, pass the raw Native Data shapes across the bridge, and completely rewrite the Dart models/, adapting the BLoCs to handle the new data shapes. Via this approach, the data pipeline is cleaner but the risk of UI regressions and scope creep is much higher during the timeline.
Please let me know, so I can resume writing the proposal!
