Open-source project
iotjin/jh_flutter_demo avatar
iotjin/jh_flutter_demo

jh_flutter_demo: A Flutter Catalogue of Components, Utilities and Screen Effects

flutter项目- 实现一些常用效果、封装通用组件和工具类

1,105 stars239 forksDartBSD-2-Clause

At a glance

What is it?
jh_flutter_demo is a Flutter application that collects common UI effects, reusable widgets and utility functions in one place, from Dio network wrappers to pickers, charts, WeChat style screens and a jh_common package holding the packaged components. It tracks Flutter releases closely, and the current build targets Flutter 3.38.2 and Dart 3.10.0.
Who is it for?
jh_flutter_demo fits a Flutter developer who wants to see how a common effect is done in a real application before writing it, and who wants a jh_common package to copy from rather than a library to depend on, since this is a demo application first. It is a poor fit as a production dependency, because the packaged code is designed for demonstration and the update record shows releases tied to Flutter version bumps rather than to features.
Can I use it commercially?
Yes. BSD-2-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 64 days ago.
What is it written in?
Mainly Dart, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A Demo Application First, a Library Second

jh_flutter_demo describes itself as a new Flutter project that implements common UI effects and encapsulates components and utilities, and the README is direct about how it should be used: the packaged components and utils are in the jh_common folder, and for more you should download the project to look.

That framing is the right way to read it. This is a full application whose pages demonstrate effects, and the reusable pieces have been gathered into one folder so they can be lifted out. The value is in the reading, since each screen is a working example of a pattern you would otherwise have to reconstruct from documentation.

The online preview at iotjin.github.io/jh_flutter_demo is a web build of the same application, which means you can look through the catalogue before you clone anything, and the README is bilingual with an English version and a Simplified Chinese version.

The project is a Dart codebase, licensed under BSD-2-Clause, and the environment is pinned. The badges and the project environment section both give Flutter 3.38.2 and Dart 3.10.0, and the top level of the repository has the usual Flutter layout with lib/, android/, ios/, web/, assets/, test/, a pubspec.yaml and an analysis_options.yaml.

Release Numbers That Track Flutter Versions

The update record is unusual and worth understanding before you judge the maintenance story. The release tags are named after the Flutter version they target rather than after a sequence of the project's own, so the tags are v3.32.0 from 2026-06-23, v3.27.0 from 2026-01-27 and v3.22.0 from 2025-03-11.

The update log explains what each one did. The v3.38.2 entry updates the pubspec libraries and the Flutter version, with the iOS minimum build version changed to 13.0 and an Android build environment upgrade. v3.32.0 brought Android 16 adaptation and a move from Java 11 to Java 17. v3.27.0 handled Android 15 adaptation, v3.22.0 handled Android 14 adaptation, and v3.16.0 raised the iOS minimum build version to 12.0 and added the Material 3 adaptation. Earlier entries go back to v1.0.0, which set Flutter 1.22.3 and Dart 2.10.3, and v2.0.0, which updated to the Flutter 2.0.3 SDK.

So the release history is really a compatibility history. Each tag exists because a new Flutter or a new Android version forced a change, which is a good sign for anyone who cares about building on a current SDK, and a hint that the project will not have a release between platform shifts.

The README also says plainly that the code is updated irregularly, and the last push was on 2026-08-20, so work continues without a strict schedule.

jh_common Is the Part You Can Reuse

The project structure is the most important part of the repository. There is a jh_common folder that holds the packaged components and utils, and the README says so explicitly.

Everything else in the list is application scaffolding in the useful sense. There is common framework construction with a common base class implementation, macro definitions for font, color, frame and string, Dio network request encapsulation, API interface management and data management, modularised management of routes, screen adaptation, dark mode adaptation, a theme switch, internationalisation through GetX, and Material 3 adaptation.

The list of components is long and specific. There are base classes for the app bar, the tab bar, the refresh view and the web view. Dialogs come in centre, bottom, toast, dialog and custom variants. The pickers cover time, date, single column, multi column and bottom single or multiple selection, plus a cascading picker that works on a multi-dimensional array or a tree structure and supports search. The JhForm component covers single row, multi row, select, setting and login input styles. There is a JhTopTabBar for navigation bar page switching, gradient and multi-line title app bars, an imitation of the WeChat top-right pop-up, a countdown button, an app update dialog, a WeChat style picture and video picker, a picture and video browser, text highlighting inside a string, empty data and network exception views, a skeleton screen, a horizontal sliding menu in the Pinduoduo and Taobao style, a full screen zoomable carousel, shake, zoom and translate animations, a wave animation, Lottie animation, a tag view and a collapse view.

That is a catalogue, and the jh_common folder is where the reusable subset of it is kept.

Utilities: Encryption, Devices, Codes and Maps

The utility list is the part most likely to be copied into a real project, and it is a mix of things you would otherwise assemble yourself.

For cryptography there is AES encryption and decryption, MD5 encryption and base64 encoding and decoding, plus local data storage that is AES encrypted, which is a sensible way to keep tokens on the device. For the device there is real-time network monitoring, and getting device information, screen information and notch screen detection, which is the detail that decides whether your layout needs a top inset. There is loading of image resources, colour settings, status bar settings, QR code scanning and generation, navigation route jumping, listening for page appearance or disappearance, time format conversion, string processing and random numbers.

Then there are the platform bits: exiting the app or jumping to the app store, debounce and throttle, and jumping to a third party map application for navigation.

The UI related section is a third list, and it covers the parts of an application that are not really widgets. There is ListView work including pull to refresh, grouped refresh and a sticking group header, GridView work, chart work with dynamic loading of multiple charts, gradient line charts and mixed line and bar charts, badges, app bar search and header search, a tag cloud animation, a list slide button, a city selection list, drag and drop sorting for both ListView and GridView, rich text, login and register screens, a version and new features page, a checking for updates flow, and a set of WeChat imitations covering the home page, address book, discover and personal centre, the app bar pull-down zoom and gradient effect, the friends circle, and a cross-slide personal centre effect.

There is also a handwritten signature feature built on signature and hand_signature libraries.

Build and Runtime Caveats You Will Hit

The precautions section is short and worth reading before you run the project.

There will be some freezes in debug mode, and the README says that is normal, that a good experience requires a release package. The two build commands given are:

bash
# iOS can execute the command `flutter build ios` to create a release version
# Android can execute the command `flutter build apk` to create a release version

The second caveat is about iOS 14, where the app crashes when running on a real device, and the README says it can be run on a real machine through flutter run --release. So the fix for the crash is the same fix as the freeze: build in release mode.

That is a fair criticism of a demo project and a fair warning at the same time. Debug builds of a large application with many animations, charts and image processing will be slow, and the project does not attempt to work around that.

The app update dialog and the checking for updates flow also imply a server contract, so those two are demonstrations of a pattern rather than a working update channel.

What the Repository Actually Contains

Beyond the code, the repository carries the assets and the screenshots that make it browsable, and those matter for a project whose main purpose is showing what something looks like.

There is a ScreenShot/ directory at the top level, and the README embeds a long sequence of preview images from a separate Gitee image repository, covering the login page, the WeChat style home, contacts, discover and personal centre screens, the base app bar, the toast and other components. The previews are what let you decide which parts are worth reading the code for, since a screenshot of a skeleton screen or a wave animation tells you more in a second than the feature list does.

The assets/ directory holds the bundled resources, and the web/ directory means the project can be built for the web, which is how the online preview is produced.

The project also has two README files, the English one and README.zh-CN.md, and the analysis_options.yaml is the Dart analyser configuration, which tells you the project is set up for static analysis rather than only for running.

Taken together, the shape of the repository is consistent with its purpose: a Flutter application that runs, shows a lot of effects, and keeps the reusable fragments in one folder for the next person to take.

Editorial conclusion

jh_flutter_demo fits a Flutter developer who wants to see how a common effect is done in a real application before writing it, and who wants a jh_common package to copy from rather than a library to depend on, since this is a demo application first. It is a poor fit as a production dependency, because the packaged code is designed for demonstration and the update record shows releases tied to Flutter version bumps rather than to features. Before adopting any of it, build a release rather than running in debug, because the README states that debug mode freezes and that a good experience requires a release package, and check the iOS minimum version, which the latest release raised to 13.0. The project is BSD-2-Clause licensed, the last push was on 2026-08-20, and the author states plainly that the code is updated irregularly.

Frequently asked questions

What is jh_flutter_demo and what is it for?

It is a Flutter project that implements common UI effects and encapsulates components and utils, and the README says the packaged components and utilities are in the jh_common folder. It is meant as a reference and a source of reusable code rather than a library to install.

Which Flutter and Dart versions does jh_flutter_demo use?

The project environment section gives Flutter 3.38.2 and Dart 3.10.0. The update record tracks the same pairing, with the v3.38.2 entry also raising the iOS minimum build version to 13.0 and the v3.32.0 entry moving from Java 11 to Java 17.

How do I run the demo without hitting the freezes?

The README notes that debug mode will freeze sometimes and that a good experience requires a release package, with `flutter build ios` and `flutter build apk` for the two platforms. It also states that iOS 14 crashes on a real device and can be run with flutter run --release.

What utilities does jh_flutter_demo provide?

AES encryption and decryption, MD5 encryption, base64 encoding, AES encrypted local storage, real-time network monitoring, device and screen information with notch detection, image loading, colour and status bar settings, QR code scanning and generation, route jumping, page lifecycle listening, time formatting, string processing, random numbers, debounce and throttle, and navigation to a third party map app.

Does jh_flutter_demo support dark mode and internationalisation?

Yes. The feature list includes screen adaptation, dark mode adaptation, a theme switch, internationalisation through GetX and Material 3 adaptation, and the update record shows the Material 3 adaptation arriving in the v3.16.0 entry.

Official sources

  1. iotjin/jh_flutter_demo on GitHub
  2. License: BSD-2-Clause
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/iotjin-jh-flutter-demo.svg)](https://hysenlabs.com/projects/iotjin-jh-flutter-demo)

Was this useful?