Fighting android canvas – Hexagonal imageview layout for Android
We made a simple design for one of our apps which included a hexagonal network of images which should contain profile pictures of the users who liked a certain app.
We made a simple design for one of our apps which included a hexagonal network of images which should contain profile pictures of the users who liked a certain app.
mGetActiveHubUpdatesInteractor.getActiveHubUpdates() .filter(Optional::isPresent) .firstOrError() .map(Optional::get) .flatMap(activeHub -> mGetActiveHubEventsInteractor.getActiveHubEvents(activeHub, startTime, endTime)) .flattenAsObservable(list -> list) .map(mActiveHubEventUiMapper::toUiActiveHubEvent) .toList() .subscribe(this::populateEvents, this::handleError);
Edit: All of this happened in the long forgotten year - 2014 It is time for me to tell you a nice story. It is a long one so you can directly go to the middle of this article, which I expect to be long, so you can get the main point.
Short Intro For 4 months now I have been implementing “clean architecture” in my current project. The project is huge, more than 17 Android developers work on it including me, so it is important to apply an architecture that works for all of us. I will not talk about what “clean architecture” is, but I will directly dive into the code and explain step by step the purpose of the layers that we have and what each layer is about.
Recently, I had a very strange problem to debug. I had the following interactor:
Do you still use it!? Have you used it? I mean the EventBus. If the answer is NO, then you are either a new developer who started Android recently or you had the wonderful opportunity to not meet this three-headed monster. What I am talking about? Let’s make a brieft visit of the Android development history.
Probably, most of you already know this, but it is good to keep it in mind when you want to dynamically change the values returned by a mock you have.
Edit 23.04.2018 According to this issue, Mockito cannot capture var-args still. There is a very easy way to verify a method has been called with the right parameter in Mockito. All you need to do is use captors, to capture the actual argument. Here is how you can use them: ArgumentCaptor argument = ArgumentCaptor.forClass(RuleEntity.class); verify(mRulesRepository).createRule(argument.capture()); assertEquals(1,argument.getValue().getRules().get(0).getTriggers().size()) Simple it is, just a quick reminder for starters.
How I used to do it The biggest problem I have with push notifications and especially GCM is testing them. Every time I want to test a notification, I would create a sample project in Google Developers Console, use the JSON there and then use Postman to send HTTP requests to the device, after obtaining the device registration id and the token for the project.
Recently, we got a bug inside the app. The app was crashing in the push notification receiver class that we had on the line where we called notificationManager.notify(notificationId, notificationBuilder.build()).