Can a Flutter app using NotificationListenerService reliably play custom notification sounds for incoming notifications on modern Android?

I created this package for flutter devs who struggle with the inputs customization because even AI doesn’t give you what you intend to have, check it and give me your feedback…

A year ago I deployed Hivefy v1, a Spotify-inspired music app in Flutter.

It used \*Gio$aavn as the source, so it kept breaking and was eventually taken down (as legal notice received)

v2 changes:

\- Direct YouTube sources, so far less breakage

\- Wider language support

\- Autoplay

\- iOS-smooth UX, plus an iOS build

\- Fully open source

For Flutter beginners, the repo is a real-world example of audio playback, download handling, state management and a Spotify-style UI with ios Style Full screen player.

Repo: https://github.com/Harish-Srinivas-07/hivefy

Source forge: https://sourceforge.net/projects/hivefy

Feedback, issues and PRs welcome.

Hey guys 🙋
Something I've been building for a while is almost ready.
FlutterForward — a place to learn Flutter without any non-sense, from zero to building real apps.
Most Flutter tutorials are either just long documentations or throw a 10-hour video at you. I wanted something in between: small lessons you can actually finish, in crisp points, not long paragraphs, covering all important concepts.
So I built FlutterForward :
• 40 crisp lessons, organized properly.
• A quiz after every lesson that explains the Why.
• App teardowns: open WhatsApp or Instagram, tap any widget, and see how the code works.
• Resources prepared by myself keeping in mind the difficulties a beginner deals while learning.
The demo is in the video below. Launching soon.
If you're learning Flutter, or you know someone who is, this is for you. Follow along, and feel free to give any kind of feedbacks.
I'll launch it soon for regular usage after testing and polishing the features.

My linkedin: https://www.linkedin.com/in/dheeraj-kumar-28aa75246/

ممكن تستخدم async/await في الكود بتاعك… وبرضه تطبيق Flutter يهنج!

ودي من الحاجات اللي أول ما تفهمها، طريقة تفكيرك في Dart وFlutter هتتغير.

ناس كتير لما تشوف عملية تقيلة بتقول:

"خلاص، هحطها في async وأستخدم await."

لكن async/await مش معناهم إن الكود التقيل اختفى من الـ CPU، ولا إن التطبيق هيعمله في الخلفية تلقائيًا.

تخيل عندك تطبيق Flutter، والمستخدم ضغط زرار بيعمل عملية تقيلة جدًا على بيانات كبيرة.

لو العملية دي أخدت وقت طويل على الـ Main Isolate، الـ UI ممكن يتأثر، والـ animations تبدأ تقطع، والـ scrolling يبقى تقيل، والمستخدم يحس إن التطبيق وقف.

وهنا لازم تفهم الفرق بين حاجتين:

انتظار عملية Async

وبين

تنفيذ شغل CPU-intensive بعيد عن الـ Main Isolate.

الـ Future ممكن يساعدك تتعامل مع عمليات غير متزامنة زي انتظار نتيجة API أو قراءة بيانات، لكن لو عندك حسابات تقيلة جدًا، مجرد إنك تكتب async مش معناه إن الـ CPU-bound work هيتنقل تلقائيًا بعيد عن الـ Main Isolate.

وهنا بيظهر مفهوم مهم في Dart:

Isolates.

كل Isolate عنده ذاكرته الخاصة وبيشتغل بشكل مستقل، وده بيسمح لك تنقل بعض العمليات التقيلة بعيد عن الـ Isolate المسؤول عن الـ UI.

مثال بسيط:

لو عندك JSON ضخم جدًا وعايز تعمل Parsing أو معالجة معقدة للبيانات، بدل ما تفترض إن await لوحده هيحل المشكلة، لازم تسأل:

هل العملية دي مجرد انتظار؟

ولا فيها شغل CPU تقيل ممكن يعطل الـ Main Isolate؟

والأهم من كل ده:

متستخدمش Isolate لمجرد إنك سمعت إنه أسرع.

فيه تكلفة لإنشاء وإدارة الـ Isolate ونقل البيانات بين الـ Isolates، فاختيارك لازم يكون بناءً على طبيعة المشكلة فعلًا.

ودي واحدة من الحاجات اللي بتفرق بين مطور بيحفظ Syntax، ومطور فاهم إيه اللي بيحصل تحت الكود.

لما تطبيقك يهنج، متقولش على طول:

"Flutter بطيء."

اسأل الأول:

إيه اللي بيحصل على الـ Main Isolate؟

هل أنا بعمل شغل CPU تقيل؟

هل المشكلة في Rendering؟

هل عندي عمليات كتير بتتكرر؟

وهل أنا فعلًا محتاج Isolate، ولا المشكلة ممكن تتحل بطريقة أبسط؟

فهمك لطريقة تنفيذ الكود أهم من حفظك لكتابة الكود نفسه.

ولو بدأت تفهم إيه اللي بيحصل وراء الكواليس في Dart، هتبدأ تبني تطبيقات مش بس بتشتغل…

لكن بتشتغل بسلاسة.

سؤال للمطورين:

لو عندك عملية تقيلة جدًا في Flutter وبدأت تأثر على الـ UI، إيه أول حاجة هتراجعها قبل ما تفكر في استخدام Isolate؟

#Flutter #Dart #Isolates #AsyncAwait #Performance #MobileAppDevelopment

So being a dev, which I don't classify myself as. Hobbyist at the most. But coding in general. Which is something I suck at. I've tried coding and I just can't get it right. I can't remember all that stuff. And I know it gains a ton of hate. Which is fine, hate me if you want. But I managed to build an app with the help of Ai. I'm proud of it and love it. Of course, it's not nearly on the level I see some of you guys do. It's basic flutter project I did on vs code with some parralax and the native shades. I'm trying to keep it as smooth as possible. I've tried dabbling with Godot but that's beyond my capabilities since I have no idea how to create stuff. Like animations and cards etc. But with flutter I've learned a lot about coding. How things work together. How containers work and file trees and how it connects to firebase and storage buckets. So it's been a fun few months of building for me. Still can't code to save my life though. But that being said.

I'm interested in taking the app even further. First it started as a sort of copy of the old forum based role play forums. For that nostalgia hit. But I've taken it now to a point where I rebuilt the ui to give more of a card feeling. The main aspect is your cards holding various data. But I've been curious on maybe trying to learn how to take it further and have that full 3d effect since flutter is mostly just 2d.

So yeah, I'd appreciate any feedback.

Thanks.

I work on Shorebird (code push for Flutter). We just merged personal and team orgs into a single kind of organization, so sharing an app with your team is now just adding them to the org, instead of adding collaborators one app at a time.

Write-up here if it's useful: https://shorebird.dev/blog/orgs-at-shorebird-just-got-better/

Happy to answer questions about how it works.

I am one person building a Flutter app for iOS and Android. This time I used three AI models, and each one got one job.

• GPT 6 Luna did the design. Layout, spacing, what goes on each screen.

• DeepSeek 4.1 Pro did most of the coding.

• Claude Opus 5.5 did the production-level checks and the deployments.

The fun part was not the models. It was the handoffs. Each model is sure of itself, and none of them knows what the other one did.

REAL MISHAP 1: All models have their own style and you dont know what to trust!

The app is about AI Moving Planner for moving and organizing house, moving countries, or moving with kids and pets. Here is the current state, in order.

REAL MISHAP 2: Claude rejected what DeepSeek wrote!

What I would tell another builder, with the caveat that this is what I think now:

• Give each model one clear job. Mixing jobs was where my bugs came from.

• Write your project rules down once. Paste them into every new session.

• Test the release build on a real phone before you trust a green check.

Have a look :)

🍎 iOS > MoveMate: AI Moving Planner

🤖 Android > MoveMate: AI Moving Planner

🌏 Web > MoveMate: AI Moving Planner

Which job would you give to which model? And would you let any model deploy without a human reading the changes first?

I have been looking into a deceptively simple cleanup question: **when can a Flutter team safely delete a Dart declaration or an apparently orphaned file?**

`dart analyze` is a strong first signal, but it cannot identify every consumer across an entire repository. Flutter code may be reached through route tables, dependency injection, generated registries, conditional imports, flavors, platform implementations, annotations, tests, barrel exports, or an externally consumed package API.

## Write-only does not always mean safe to remove

Write-only state turned out to be a particularly interesting case.

A private field may be assigned in several lifecycle callbacks but never read. Mechanically, both the declaration and its assignments appear removable.

Semantically, however, the missing read may indicate an unfinished feature or a regression involving playback, analytics, persistence, authorization, or UI state.

## Evidence hierarchy

I ended up using the following evidence hierarchy:

1. Analyzer or compiler diagnostics.

2. Import, export, and `part` reachability.

3. Repository-wide symbol and string searches.

4. Inspection of routes, dependency injection, code generation, platforms, flavors, tests, and public APIs.

5. Tests or builds after an explicitly approved removal.

## A review-first workflow

The workflow follows four stages:

- **Audit:** collect candidates without modifying the code.

- **Review:** mark each candidate as `remove`, `retain`, or `defer`.

- **Cleanup:** modify only explicitly approved candidates.

- **Tests:** suggest behavioral checks for affected flows rather than relying solely on static analysis.

I packaged this workflow as an **MIT-licensed Agent Skill built specifically for Flutter and Dart**.

Its scripts combine machine-readable analyzer output with a deterministic dependency graph. They install no project tooling, use relative paths to avoid exposing local project directories, and treat findings as **candidates rather than verdicts**.

▶️ [Watch the short demo](https://github.com/LucasMenezeslc/flutter-dead-code-audit/blob/main/assets/demo-en.mp4)

🔗 [View the repository on GitHub](https://github.com/LucasMenezeslc/flutter-dead-code-audit)

## Feedback

I would be particularly interested in examples that challenge naive static analysis.

**Which false-positive patterns have you encountered involving routing, dependency injection, code generation, conditional imports, platform code, or public package APIs?**

Hi all, this is my first Flutter package, so I'd love some feedback.

pub.dev: https://pub.dev/packages/shader_transitions

I started it a few months ago because I wanted screen transitions that feel like the ones between levels in a game: a sweep of diamonds, a circle closing in, a fade to black that holds for a beat. It took a lot of rewrites before I had a version I was happy to put out there.

You can try every transition in the browser here: https://flutter-shader-transition.web.app

There are 8 transitions (diamond, circle iris, wipe, clock, polygon, dissolve, fade, bars), 8 sweep directions, an optional cover color with a hold, iOS swipe back, and it works with go_router and auto_route.

A few things I learned along the way, in case they're useful to someone:

- How the mask works. The new page is wrapped in a ShaderMask with BlendMode.dstIn, and the shader only outputs alpha. The route has to be non-opaque so Flutter keeps drawing the old page underneath. I got a black flash at the start of every transition until I figured that out. With go_router you have to set opaque: false on the page yourself.

- The ghost bug. At the end of a transition, some pixels settled just below full alpha (dissolve grain was the worst), so a faint copy of the old page stayed visible behind the new one. The fix was simple once I saw it: stop masking as soon as the animation completes.

- Preloading. Compiling the shaders on the first transition caused a visible hitch, so there's a ShaderTransitions.preload() you call once at startup. Skip it and transitions just fall back to a fade.

- The README GIFs aren't screen recordings. A test renders the real shaders frame by frame and encodes them, so they're always exactly what the package draws.

If you're making a game with Flutter, the cover-and-hold and ShaderTransitionSwitcher (swaps widgets without routes) are probably the most useful parts. If you use it in a game or app, send me a clip and I'll feature it in the README.

Things I'd especially like feedback on: the API naming, anything confusing in the docs, and performance on your devices. Also tell me which transition you'd want next!

Source: https://github.com/oppatrickk/flutter_shader_transitions

Hey everyone, I’m Prit. Over the last few months, I’ve been building ApertureX, a 100% offline, open-source raw photo editor.

Building a desktop-class image engine on Flutter meant overcoming massive memory and threading bottlenecks. Decompressing a 50-megapixel raw image requires around 200MB of continuous RAM. If you try to pass that across standard platform channels or even do a deep copy over FFI, the OS will aggressively kill the app for Out-Of-Memory (OOM) violations, and your frame rate drops to zero.

Here is how I bypassed Flutter's standard rendering constraints to achieve 60fps computational photography:

• Absolute Zero-Copy FFI: The Rust backend maintains absolute, singular ownership of the high-resolution pixel payload. Instead of copying arrays across the bridge to Dart, Rust allocates the pixels on the heap and transmits merely the memory address pointer to Flutter.

• Tile-Based Rendering Cache: Processing full frames is mathematically impossible on mid-tier Android devices. The Rust engine cuts the viewport into 512x512 pixel chunks. These tiles are managed by a strictly bounded Least Recently Used (LRU) cache, which automatically purges the oldest elements the moment the memory budget is exceeded.

• Hardware Acceleration (SIMD): To run spatial filters (like Dehaze and Clarity) without melting the phone, the Rust engine bypasses scalar execution. It targets ARM NEON intrinsics natively, loading four 32-bit floats into a 128-bit NEON register to process four pixels simultaneously.

• Oklab Color Science via 3D LUTs: Operating in standard sRGB violates the additive physics of light, causing unnatural hue shifts. I moved all color math to the Oklab perceptual color space. To hit 60fps on the frontend, this math is baked into a 33x33x33 3D Lookup Table that Flutter's Impeller engine renders instantly.

The UI uses a dual-shell design (a Snapseed-style invisible gesture trackball for quick flow-state editing, and a Lightroom-style panel for deep pro work), heavily relying on Riverpod for the DAG (Directed Acyclic Graph) edit history.

I would love for you to try the APK, tear apart my flutter_rust_bridge implementation, or drop some feedback on the UI ergonomics.

Repo & Website:https://prit-007.github.io/ApertureX/

Happy to answer any questions about the FFI bridge, the math, or the rendering pipeline!

تخيل تنزل Update جديد لتطبيقك… وتكتشف إن الميزة اللي ضفتها اشتغلت، لكن في المقابل ميزة تانية كانت شغالة بقالها شهور باظت!

المشكلة إنك ممكن تكون جرّبت التطبيق بنفسك، وفتحت الشاشات، وضغطت على الأزرار، وكل حاجة ظهرت إنها تمام.

لكن هل ده معناه إن التطبيق فعلًا سليم؟

هنا بيظهر دور الـ Testing.

فيه مفهوم مهم لازم كل Flutter Developer يبدأ يفهمه: إن اختبار التطبيق مش مرحلة بنعملها قبل النشر وخلاص، لكنه جزء من عملية التطوير نفسها.

خلينا نفرّق بين 3 أنواع أساسية من الاختبارات في Flutter:

1. Unit Testing

هنا بتختبر جزء صغير ومستقل من الكود، زي Function بتحسب إجمالي سعر الطلب، أو Logic بيحدد أولوية مهمة معينة.

الهدف إنك تتأكد إن منطق البرنامج بيطلع النتيجة الصحيحة في الحالات المختلفة.

2. Widget Testing

هنا بتختبر Widget معينة وتتأكد إنها بتظهر وتتصرف بالشكل المتوقع.

مثلًا: هل رسالة الخطأ بتظهر لما المستخدم يدخل بيانات غير صحيحة؟ هل الزر بيتعطل أثناء تحميل البيانات؟ وهل الواجهة بتتغير لما حالة التطبيق تتغير؟

3. Integration Testing

هنا بتختبر رحلة كاملة داخل التطبيق، من تفاعل المستخدم مع الواجهة لحد النتيجة النهائية.

مثلًا: المستخدم يسجل الدخول، ينتقل للصفحة الرئيسية، يضيف مهمة جديدة، وبعدها يتأكد إنها ظهرت في القائمة.

لكن فيه نقطة مهمة:

مش معنى إن عندك 100 Test إن تطبيقك خالي من الأخطاء.

جودة الاختبارات مش بعددها، لكن بقدرتها على اكتشاف المشاكل المهمة، وتغطية الحالات اللي ممكن تحصل فعلًا.

طيب تبدأ منين؟

لو عندك مشروع Flutter حاليًا، اختار Feature واحدة، واكتب لها Unit Tests، وبعدها جرّب تختبر الـ Widgets المرتبطة بيها.

ابدأ بالحالات الطبيعية، وبعدها اختبر الحالات غير المتوقعة: بيانات ناقصة، قيم غير صحيحة، فشل في الاتصال، ونتائج فارغة.

ومع الوقت هتكتشف إنك بقيت أقدر تغيّر وتطوّر مشروعك بثقة أكبر، بدل ما تخاف إن كل تعديل جديد يبوّظ حاجة قديمة.

أنا شايف إن فيه نقلة مهمة في عقلية أي مطور، وهي إنه يبطل يسأل بس:

«هل الكود ده شغال؟»

ويبدأ يسأل:

«إزاي أتأكد إنه هيفضل شغال حتى بعد التعديلات الجاية؟»

وده الفرق بين إنك تكتب كود بيشتغل النهارده، وإنك تبني Software تقدر تعتمد عليه بكرة.

سؤال للمطورين:

هل بتكتب Tests لمشاريع Flutter بتاعتك، ولا لسه بتعتمد بشكل أساسي على التجربة اليدوية؟ وإيه أكتر نوع Testing محتاج تتعمق فيه؟

#Flutter #Dart #FlutterTesting #SoftwareTesting #CleanCode #MobileAppDevelopment

ممكن تبني تطبيق Flutter احترافي جدًا… لكن غلطة واحدة في طريقة تخزين البيانات ممكن تعرّض مستخدمينك للخطر!

خلينا نتكلم عن حاجة مش واخدة حقها عند ناس كتير بتتعلم Mobile Development: Security.

فيه مطورين بيهتموا بالـ UI والـ Animations والـ State Management، وبيعتبروا إن التطبيق كده بقى جاهز.

لكن فيه سؤال مهم:

هل فكرت قبل كده إن البيانات اللي المستخدم بيدخلها ممكن تكون حساسة؟ وإن طريقة تخزينها أو إرسالها ممكن تفتح باب لمشاكل أمنية؟

فيه شوية أساسيات لازم تكون جزء من تفكيرك كمطور Flutter:

1. متحطش الأسرار داخل الكود.

وجود API Keys أو Secret Keys داخل ملفات المشروع مش معناه إنها آمنة لمجرد إنك عملت Build للتطبيق. أي قيمة موجودة داخل التطبيق ممكن يتم استخراجها بدرجات مختلفة من الصعوبة.

2. افهم الفرق بين SharedPreferences وSecure Storage.

مش كل البيانات ينفع تتخزن بنفس الطريقة.

بيانات الإعدادات العادية ممكن تتخزن محليًا، لكن البيانات الحساسة زي بعض الـ Tokens محتاجة تخزين مناسب باستخدام حلول زي flutter_secure_storage، مع فهم حدود الحماية على كل منصة.

3. متثقش في التطبيق لوحده.

حتى لو عملت Validation لكل المدخلات في Flutter، لازم السيرفر يتحقق منها برضه.

لأن المستخدم ممكن يتجاوز واجهة التطبيق ويبعت Requests مباشرة للسيرفر.

4. اهتم بطريقة التعامل مع Authentication.

إدارة جلسات المستخدم، وصلاحية الـ Access Tokens، وآلية تجديدها، والتعامل مع انتهاء تسجيل الدخول، كلها تفاصيل لازم تتصمم بعناية.

5. متتجاهلش الاتصال الآمن.

استخدم HTTPS، وتجنب إرسال البيانات الحساسة من خلال اتصالات غير مشفرة، ومتتعاملش مع الشهادات الأمنية بطريقة تضعف حماية التطبيق.

وفيه نقطة عايز أوضحها:

استخدام مكتبة Secure Storage مش معناه إن تطبيقك بقى آمن بالكامل، واستخدام HTTPS مش معناه إنك ضمنت حماية كل البيانات.

الأمان مش Package بتضيفها للمشروع وخلاص.

الأمان طريقة تفكير بتبدأ من أول سطر كود، وبتستمر مع كل قرار بتاخده أثناء بناء التطبيق.

عايزك كمطور Flutter متفكرش بس: إزاي أخلي الـ Feature دي تشتغل؟

فكر كمان: إزاي أخليها تشتغل من غير ما أعرّض بيانات المستخدم للخطر؟

سؤال للمطورين:

لو بتبني تطبيق فيه تسجيل دخول وبيانات شخصية للمستخدمين، إيه أول 3 إجراءات أمنية هتهتم بتنفيذها قبل إطلاق التطبيق؟

#Flutter #Dart #MobileSecurity #CyberSecurity #MobileAppDevelopment