Giter VIP home page Giter VIP logo

cgeo-status's Introduction

c:geo

c:geo is an open-source, full-featured, always ready-to-go client for geocaching.com (unofficial). It also offers basic support for other geocaching platforms. It does not require a web browser or exports - just download and start right away.

Want to contribute?

Perfect! Please tell us in the issue tracker before hacking on your great new feature. It would be bad for you to have implemented something great but we can't include it because it doesn't fit the existing architecture and code.

Starting points for contribution

You can also take a look at the project page of our repository. We have a list of good first issues, that might be suitable for your first contribution, and a collection of high priority issues.

Project status

Build Status
Codacy Badge
Crowdin

Get the source

Fork the project source code, make changes to your clone, and create a pull request afterwards.

Note: make sure to really fork the source code, do not just clone the main c:geo repository. Then work locally with a clone of your fork. Otherwise you won't be able to bring your changes into c:geo later. If you are a github / git beginner and don't know what this means, consult our git/github setup page for beginners.

Branches

  • master is for the development of new features. Nightly builds are created from this branch.
  • release is for all bug fixes of already existing features. So if a bug is reported in a released version, it should be fixed on this branch (and merged to master afterwards).

Note: Regular merging of release to master (after changes have been done on release) is highly recommended to avoid unnecessary merge conflicts later on.

A more complex bugfix can first be tested against the master branch and integrated in the nightly builds while kept compatible with the release branch for a later integration. Such a procedure is described in the wiki.

Setting up an IDE

The standard IDE for Android projects is Android Studio, which is based on IntelliJ IDEA. We use it for the development of c:geo.

Details for setting up the IDE are described in the wiki (https://github.com/cgeo/cgeo/wiki/IDE).

Build

Prerequisites

  • Android SDK (latest version) including Google APIs (at least) V26, Google repository, and Android support repository. (File => Settings, Appearance & Behaviour => System Settings => Android SDK, Check "Show Package Details" on "SDK Platforms" tab and check subpackages as needed.)
  • If you use Microsoft Windows, Google USB Driver to install the application on the smartphone.
  • You need to provide several API keys for compiling the app (see following sections for details).

API keys

For the full usability of c:geo you need some API keys for Google Maps and the opencaching sites. You can leave all entries in the configuration empty, but Google Maps and the Opencaching sites will not work.

For using the Google Maps function, it is necessary to have a Google Maps API v2 key. For this, follow

The key itself is free and you don't have to enter any credit card info (although the web form seems to force you to).

To be able to use Google Maps you need to use a Google API-enabled image, so make sure to select the right image for your emulator/device, otherwise Google Maps won't be offered as a map provider in c:geo.

Request your personal API key for the various OpenCaching sites we support. If you leave these blank, those networks will remain disabled.

To obtain an API key for geocaching.su you need to request access from administration. Keys are generated manually on request.

API keys installation

For c:geo we have a semi-automatic configuration:

  1. Copy ./templates/private.properties to ./
  2. Edit private.properties with your keys
  3. The ./main/src/main/res/values/keys.xml is created on the gradle build and filled with the data from private.properties

The third point works only if the file keys.xml does not exist. When changing your API keys, you have to delete the keys.xml file.

If you want to fill the keys.xml by hand, copy ./main/templates/keys.xml to ./main/src/main/res/values/, then edit the copied keys.xml. For each key, replace the value starting with @ and ending with @ (inclusive) with the key. If a key is missing, remove the value and the leading and trailing @.

Building with gradle

Run gradlew from the root directory of the git repository. That will install the necessary build framework and display how to build c:geo. gradlew assembleBasicDebug might be a good start. Alternatively you can use "make" in Android Studio ("Build" => "Make Project").

To be able to create an installable Android package (APK), you need to create a signing key first. In Android Studio go to "Build" => "Generate Signed Bundle & APK", select "APK", and follow the instructions. You will create a key storage and a project-specific key. Enter path and access information to those in file cgeo/private.properties.

Testing

The Test classes can be found in the project test. Test classes should be located in the same package as the class under test. Every class can be run with Run '<class name>' or debugged with Debug '<class name>') as an Android JUnit Test. To run all tests use the same Run 'Tests in <package name>' menu item from the context menu of a package in the test project.

For tests to run successfully you need to configure c:geo on the emulator that runs the test with a valid geocaching.com account. In order for all tests to be successful the account needs to be a premium member.

Tests may also be launched from the command line. Use gradlew assembleBasicDebug from the root directory of the git repository.

Deploying the app locally for testing purposes

Android Studio needs to be configured for which device(s) c:geo will be deployed to. Use "run" => "run" (2nd entry with this heading). You can create several profiles for a physical device attached via USB, as well as virtual devices that are run in an emulator. (If the emulator is not installed yet, do so via File => Settings, Appearance & Behaviour => System Settings => Android SDK, tab "SDK Tools", check "Android Emulator", and apply.)

License

c:geo is distributed under the Apache License, Version 2.0.

This product includes software developed by the c:geo team and contributors as well as parts developed elsewhere. See the references in main/src/main/res/values/strings_not_translatable.xml for details (or "about: contributors" page in the app).

Contact

cgeo-status's People

Contributors

lineflyer avatar samueltardieu avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

lineflyer

cgeo-status's Issues

Wrong counting after recent change of version

Today I pushed some update to status.cgeo.org to update the current release and legacy version and also built a new nightly NB1 for testing purposes (which also triggered an udpate).

Some minutes after that the status page shows an unlikely amount of "old nightly"
Also some days ago I have seen an unlikely high amount of users on "old release".

I assume there is some glitch in the counting.

2017-03-29 21_54_18-c_geo deployment status

Count for "old release" is of course reasonable in this case.

More info for older versions

It would be useful if one could click on the heading older versions to get a detailed list of all those versions divided into the categories older nightly and older releases.

Custom notfication depending on version

In some cases it would be good to have the ability to restrict notifications to certain versions of c:geo or at least to define a upper limit of the version number for which the notification is shown.

Example:
We currently have a notification regarding the live map issue.
If a user updates from 2016.11.05 (old release version) to 2016.12.28 (release where this is fixed) he will still see the notification once he starts up the new version. That is irritating for the user.
If we could post a notification and define to show it only on version codes <= 2016.11.05 this would solve this problem.

Condition rule not working

Either I made a mistake or something is not working as it should.
I created a notification which should target everything except RC-versions (kind != "rc").

However it keeps showing for me in current RC under deployment.

Deprecated Redis database for cgeo-status

@samueltardieu Not sure if anything needs to be done here, or whether we are fine with automatic upgrading?

Message from Heroku:

On March 10, 2021, we announced the Heroku Redis Hobby Tier Version Deprecation. Your Redis database redis-tapered-54000 on cgeo-status is running the deprecated version (4.0.14) which will not be supported after June 30, 2021. We recommended upgrading your Redis database to the latest version supported by Heroku, which is currently 6.0.12. We perform heavy testing and validation work on all new Redis releases, including testing the upgrade procedure, and are careful to only recommend versions that we trust. You can upgrade your Redis database to the latest default version by creating a fork on the latest version and promoting it as your active add-on. You can read more about this procedure in our Dev Center article. If you do not take action, we will upgrade your Redis database on or after June 30, 2021. Please open a ticket if you have any questions about this process.

Set default repository branch to main

The default repository branch should be set to "main" instead of the deprecated "master" (this is also what Heroku will use). The "master" branch can then be deleted ("main" contains the same thing).

Assigning @Lineflyer as I don't have the permissions to do that.

Custom notification should get higher prio than default update notification

I just posted a custom notification for kind == "release" && versionName < "2017.03.19" but it seems it is not actively seen by users as the older versions will be kind == "old release" and thus receive the default update notification.
It would be more helpful if either the custom notification gets higher priority than others or the custom notification would also support other kind values (such as oldrelease etc.)

This would allow us to notify the users about special (urgent) needs to update.

Close out old legacy versions from status notifications

As mentioned in cgeo/cgeo#6334

We have to close out the current legacy version (and older versions) from the notification system as otherwise those will be informed about the upcoming new legacy versions which are not suitable for those devices.

So devices running version code 20140342 or earlier should not receive an information once we reuse the legacy environment for the new legacy version(s).

GUI for notfication system

From IRC:
08:52:19 mucek4: OneEyed, Any chanse we get GUI for notification system?
08:53:05 OneEyed: mucek4: sure. Open an issue on cgeo-status, and I'll do that, that would be easy to add (just a HTML page with some Javascript that uses the API).
08:53:49 mucek4: but we need some sort of password auth system
08:53:55 mucek4: maybe github auth?
08:54:19 OneEyed: If it's easy to integrate, I'll use that, it would be the most consistent solution indeed.

End of life of Heroku-16 stack

Your Heroku account has one or more apps running on the Heroku-16 stack, which reaches end-of-life on May 1st, 2021.

What do I need to do?
Please upgrade your Heroku-16 apps to a newer stack using our Dev Center Guide.

What will happen to apps that are not upgraded?
From March 15th, 2021: To ensure all users notice the end-of-life warnings, a Heroku-16 app's first deploy of the week will fail; all subsequent deploys are unaffected and your apps will continue to run. The frequency of these periodic alerts will increase as the end-of-life date draws closer, as outlined in the linked changelog article.

From May 1st, 2021: Heroku-16 will have reached end-of-life. Existing Heroku-16 apps will continue to operate, but they will no longer receive security updates and they will run at your own risk.

From June 1st, 2021: The building of Heroku-16 apps will no longer be allowed. All other non-build functionality will continue to work, and the apps will continue to run.

What apps do I have on the Heroku-16 stack? 
Your account ************ has the following personal and/or team apps running on Heroku-16:

cgeo-status

Note: This may be a partial list and will not reflect changes made in the last week. For the definitive list of apps, use the Heroku CLI commands. provided in the Heroku End-Of-Life FAQ.

.

Support localized notifications

Up to now only standard notifications are localized but custom notifications are only possible in one language.

It should be possible to push self created notifications (not including message_id for localisation in cgeo) in several languages.
Depending on the locale of the device the matching language should be shown, fallback languages should be English.

For CI the dialog for creating a notification should allow to add more languages if needed as an optional step.

Server error in recent logs

Don't know if this is relevant or a temporary disturbance.
Just today I tested with a RC currently under deployment (will probably never be released) and have seen this in the log:

22:48:10.214 Debug cgeo 12118  [OkHttp] GET https://status.cgeo.org/api/status.json?version_code=20170211&version_name=2017.02.12-RC&locale=de_DE
22:48:10.761 Debug cgeo 12118  [OkHttp] 500 [Internal Server Error] (562 ms) GET https://status.cgeo.org/api/status.json?version_code=20170211&version_name=2017.02.12-RC&locale=de_DE (http/1.1)

Add services statistics

Is it possible to have also statistics about services usage? Something like
Geocaching.com - 90%
Opencaching - 7%
Extremecaching - 2%
Geocaching.su - 1%

RC notification should have target URL to Google Play

Now that we use Google Play beta channel for RC versions it could be better to target the "New RC available" notification to the standard c:geo Google Play URL (like for new release) instead of our own download server.

Advantage:

  • A new RC might be created before it is published to the beta channel
  • Only installations via Google Play will return crash reports and alike

Wrong display of users online?

Since some days whenever I open the status page it shows a higher percentage of users on "Old release" than on "2015.10.30". (e.g. 4500 current, 6100 old)
That seems like a bug for me as it was the a major percentage on the new release the weeks before already. However I don't know possible reasons for status to show up wrong.

Allow more than one custom notification

As the custom notification system allows conditions to be set, it would be beneficial if more than one custom noctification at the same time are supported.

Example:

  • Notify kind == "nightly" about a new feature
  • In parallel notify versionName == "20160101" that this version does no longer work

To work smoothly this would also require to selectively clear single notifications of course.

Kind of depends on #17 to work as intendend

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.