To teach myself Java coding and Android development - and because I couldn't find one on FDroid - I decided to write myself a little Android calorie tracker app for my own, personal use.

It's in a very basic and rudimentary state and - while it works - lacks a lot of desired functionality (like the ability to edit or remove entries) and many of the trappings of a "real" Android app (like proper icons).

The primary goal of this project is to continue development on the app and get it to a state where I can then put it on github/gitlab/bitbucket/… without having to be embarassed about it.

If you would like to join and contribute, I will figure out a way to share the git repo and the issues/TODOs I had in mind with you.

WARNING: I'm a total n00b in both Android and Java and my SQL is more middling than good.

Looking for hackers with the skills:

android java

This project is part of:

Hack Week 17 Hack Week 18

Activity

  • over 5 years ago: mbrugger liked this project.
  • over 5 years ago: anag liked this project.
  • over 6 years ago: gniebler left this project.
  • over 6 years ago: gniebler started this project.
  • over 6 years ago: gniebler added keyword "android" to this project.
  • over 6 years ago: gniebler added keyword "java" to this project.
  • over 6 years ago: gniebler originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Sipario, less mobile phone, more social interactions by baldarn

    Mobile phone usage is addictive. There are adults addicted, but a huge problem is kids addiction We must do something to help avoid problems in this context.

    The solution

    Sipario, an app and community aggregator in order to help with smartphone addiction.

    Description

    The more you use Sipario, the more points you earn. If you use the smartphone, you will lose your points

    Business model

    How is this sustainable?

    I personally don't care, but sutainability of the business is key to possible investments.

    Sipario will allow commercial entities to join the network. The idea is to give commercial activities (eg: restourants, cinemas, theathers, ....) the ability to certify that users are not using the smartphones during the permanence in the place. this will allow then commercial activities to give coupons to users, in order to promote a good behavior and retain the customer

    Tech challenge

    if resources allows it, i would like to create an algorithm that leverage bluetooth for certify people proximity presence in order to avoid attacks from points rouge in the context of the app

    Goals

    Deliver:

    • android app
    • IOs app (some apple developers must join in order to do this)
    • backoffice app
    • BLE algorithm to certify nearby presence

    Resources

    https://en.wikipedia.org/wiki/Problematicsmartphoneuse

    https://pattidigitali.it/

    https://www.forbes.com/sites/garystern/2019/04/17/the-new-york-city-restaurant-that-prohibits-cell-phone-use-facing-backlash-or-cheers/

    Similar app

    https://play.google.com/store/apps/details?id=com.ascent&hl=en

    https://www.forestapp.cc/

    Website

    https://sipario.org


    Create an Android app for Syncthing as part of the Syncthing Tray project by mkittler

    Description

    There's already an app but code/features already in Syncthing Tray could be reused to create a nicer app with additional features like managing ignore patterns more easily. The additional UI code for the app could then in turn be re-used by other parts of Syncthing Tray, e.g. to implement further steps in the wizard as requested by some users. This way one "UI wrapper codebase" could serve GNU/Linux, Windows and Android (and in theory MacOS) at the same time which is kind of neat.

    Goals

    • DONE: Learn more about development for Android and development of UIs with Qt Quick
    • DONE: Create an experimental app reusing as much existing Syncthing Tray code as possible
    • DONE: Build Syncthing as a library also for Android and use it in the app (already done but needs further testing and integration with the rest of the app configuration)
    • DONE: Update the Syncthing Tray website, documentation
    • Extend the app so it has at least a start page and an import that can cope with an export of the other app
    • Update forum thread
    • Upload an experimental build on GitHub
    • Extend the Syncthing API to download single files on demand (instead of having to sync the whole directory or use ignore patterns)

    Resources

    • Android SDK/NDK and emulator
    • Qt Quick


    Grapesss: a physical Shamir's Secret Sharing application [ESP32-C3 + Mobile] by ecandino

    drawing

    Description

    A couple of years ago I created StegoSecretS, a small cli used to encrypt and split a secret into multiple keys, using the Shamir's Secret Sharing algorithm.

    The idea is to re-implement the project using physical devices. One device alone will be useless, but when close together they can be used to decrypt the secret.

    On a practical side the user encrypts the secret with a mobile application. The same application is used to split the secret, and load the partial keys into different micro-controllers. Another user will be able to decrypt the secret only having at least N devices close together (using the application).

    I'm planning to use a couple of ESP32-C3 I bought, and build a very simple Android mobile application.

    Goals

    • Learn about Rust and micro-controllers (ESP32-C3)
    • Learn about mobile applications (Android and Kotlin)

    Resources


    Testing and adding GNU/Linux distributions on Uyuni by juliogonzalezgil

    Join the Gitter channel! https://gitter.im/uyuni-project/hackweek

    Uyuni is a configuration and infrastructure management tool that saves you time and headaches when you have to manage and update tens, hundreds or even thousands of machines. It also manages configuration, can run audits, build image containers, monitor and much more!

    Currently there are a few distributions that are completely untested on Uyuni or SUSE Manager (AFAIK) or just not tested since a long time, and could be interesting knowing how hard would be working with them and, if possible, fix whatever is broken.

    For newcomers, the easiest distributions are those based on DEB or RPM packages. Distributions with other package formats are doable, but will require adapting the Python and Java code to be able to sync and analyze such packages (and if salt does not support those packages, it will need changes as well). So if you want a distribution with other packages, make sure you are comfortable handling such changes.

    No developer experience? No worries! We had non-developers contributors in the past, and we are ready to help as long as you are willing to learn. If you don't want to code at all, you can also help us preparing the documentation after someone else has the initial code ready, or you could also help with testing :-)

    The idea is testing Salt and Salt-ssh clients, but NOT traditional clients, which are deprecated.

    To consider that a distribution has basic support, we should cover at least (points 3-6 are to be tested for both salt minions and salt ssh minions):

    1. Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    2. Onboarding (salt minion from UI, salt minion from bootstrap scritp, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator)
    3. Package management (install, remove, update...)
    4. Patching
    5. Applying any basic salt state (including a formula)
    6. Salt remote commands
    7. Bonus point: Java part for product identification, and monitoring enablement
    8. Bonus point: sumaform enablement (https://github.com/uyuni-project/sumaform)
    9. Bonus point: Documentation (https://github.com/uyuni-project/uyuni-docs)
    10. Bonus point: testsuite enablement (https://github.com/uyuni-project/uyuni/tree/master/testsuite)

    If something is breaking: we can try to fix it, but the main idea is research how supported it is right now. Beyond that it's up to each project member how much to hack :-)

    • If you don't have knowledge about some of the steps: ask the team
    • If you still don't know what to do: switch to another distribution and keep testing.

    This card is for EVERYONE, not just developers. Seriously! We had people from other teams helping that were not developers, and added support for Debian and new SUSE Linux Enterprise and openSUSE Leap versions :-)

    Pending

    FUSS

    FUSS is a complete GNU/Linux solution (server, client and desktop/standalone) based on Debian for managing an educational network.

    https://fuss.bz.it/

    Seems to be a Debian 12 derivative, so adding it could be quite easy.

    • [W] Reposync (this will require using spacewalk-common-channels and adding channels to the .ini file)
    • [W] Onboarding (salt minion from UI, salt minion from bootstrap script, and salt-ssh minion) (this will probably require adding OS to the bootstrap repository creator) --> Working for all 3 options (salt minion UI, salt minion bootstrap script and salt-ssh minion from the UI).
    • [W] Package management (install, remove, update...) --> Installing a new package works, needs to test the rest.
    • [I] Patching (if patch information is available, could require writing some code to parse it, but IIRC we have support for Ubuntu already). No patches detected. Do we support patches for Debian at all?
    • [W] Applying any basic salt state (including a formula)
    • [W] Salt remote commands
    • [ ] Bonus point: Java part for product identification, and monitoring enablement


    SUSE AI Meets the Game Board by moio

    Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!
    A chameleon playing chess in a train car, as a metaphor of SUSE AI applied to games


    Results: Infrastructure Achievements

    We successfully built and automated a containerized stack to support our AI experiments. This included:

    A screenshot of k9s and nvtop showing PyTAG running in Kubernetes with GPU acceleration

    ./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)

    Results: Game Design Insights

    Our project focused on modeling and analyzing two card games of our own design within the TAG framework:

    • Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
    • AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
    • Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .

    Cards from the three games

    A family picture of our card games in progress. From the top: Bamboo, Totoro, R3

    Results: Learning, Collaboration, and Innovation

    Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:

    • "Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
    • AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
    • GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
    • Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.

    Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!

    The Context: AI + Board Games