Данные, хранящиеся в приложении расширения класса, возвращают ноль - PullRequest
Новая
       59

Данные, хранящиеся в приложении расширения класса, возвращают ноль

0 голосов
/ 17 марта 2020

У меня есть класс данных, который расширяет Application, и один из наборов данных, который он должен хранить, представляет собой HashMap из местоположений POI и времени посещения. 

public class CharacterSheet extends Application {
private HashMap<PointOfInterest, Date> coolDowns = new HashMap<>();

    public HashMap GetAllCoolDowns() { return coolDowns; } //dev only?
    public Date GetCoolDown(PointOfInterest poi) {return coolDowns.get(poi);}
    public Date PutCoolDown(PointOfInterest poi, Date date) {return coolDowns.put(poi, date);}}

. Затем, при работе с картами Google, я беру OnPOIclick. 

    @Override
public void onPoiClick(final PointOfInterest poi) {

    //POI Cool Down
    Date currentTime = Calendar.getInstance().getTime();
    Date lastTime = ((CharacterSheet) this.getApplication()).GetCoolDown(poi);//this ONLY returns null??

    if (lastTime != null){
        int timeDiff = currentTime.compareTo(lastTime);
        makeToast("Time Since last visit: " + timeDiff );
    } else { makeToast("First");
        }

    ((CharacterSheet) this.getApplication()).PutCoolDown(poi, currentTime);
    makeToast("This?" + ((CharacterSheet) this.getApplication()).GetCoolDown(poi));}

Порядок должен быть следующим: «Нажми poi», «Получи текущее время ... получи в последний раз, если последний раз был нулевым ... никогда не было раньше», сохраняй время и дату в хэш-карте с poi в качестве ключа

В следующий раз появится и этот раз в прошлый раз не должен быть нулевым, так как мы сохранили этот poi и время уже .. но независимо от того, что он возвращает ноль ..

Последняя строка кода является помощником makeToast сообщая мне, что находится в классе данных ... это дает мне значение даты, когда я нажал не нулевое значение

В OnPOIClick есть фрагмент, сгенерированный позже, но еще до того, как пользователь сможет что-либо сделать, на что вы в конечном итоге смотрите, и вам приходится «отступать», я не знаю, как это могло бы повлиять на это, поскольку весь код завершен еще до вызова данных для фрагмента, но чувствую следует упомянуть 

        PlacesClient placesClient = Places.createClient(this);
    String placeId = poi.placeId;
    List<Place.Field> placeFields = Arrays.asList(Place.Field.ID, Place.Field.TYPES);
    FetchPlaceRequest request = FetchPlaceRequest.newInstance(placeId, placeFields);

    placesClient.fetchPlace(request).addOnSuccessListener(new OnSuccessListener<FetchPlaceResponse>() {
        @Override
        public void onSuccess(FetchPlaceResponse fetchPlaceResponse) {
            Place place = fetchPlaceResponse.getPlace();
            PlaceDataHolder holder = new PlaceDataHolder(place);
            String placeName = poi.name;
            makeLootFragment(holder,placeName);

Запущенный фрагмент - это весь смысл нажатия на POI, поэтому, если это так, мне нужно подумать о другом способе обработки перезарядки ... но я действительно не понять, почему это может помешать.

1 Ответ

0 голосов
/ 19 марта 2020

Я не задумывался о возвращенном PointOfInterest. Он поставляется с UUID для каждого запроса, что делает его бесполезным в качестве ключа, так как каждый раз, когда я нажимал на него, менялся ... это было обнаружено путем изменения моей проверки после операции, чтобы убедиться, что она вошла в hashMap, к просмотру содержимое всей hashMap, вскоре увидел, что записи, которые накапливаются, несмотря на нажатие только одного poi

, решить это было достаточно просто. Я создал новую строковую переменную из poi.name и использовал ее вместо poi, мне пришлось изменить HashMap так, чтобы он принимал String, а не PointOfInterest

...