Problems with serializing RxAndroidBle classes - rx-android

My app attempts to pass a fairly complex object that uses RxAndroidBle classes from one Android activity to another by adding it to an Intent as a Serializable extra. But I'm getting crashes, apparently due to problems with serialization of these classes.
Is there any fix for this?

Unfortunately it is not possible to serialize classes of RxAndroidBle because most of them contain references to objects that are not serializable.
If you cannot pass a reference to an object that you want to use in a different part of the code (for instance in a different process) then you would need to create a new instance of RxBleClient in that process and use it.

Related

Axon Framework EventStore ReadEvents Serialization Problem

5.5 and axon framework starter 4.5.4
I can read and write my events with eventhandler and queryhandler without problem
but when I want to use eventstore.readevents function I got serialization .I try to set my application properties both my reader and writer but not working still same error(By the way I clean database and delete old events each time).I alson try to set xstream type but still same issue
axon.serializer.general=jackson
axon.serializer.events=jackson
axon.serializer.messages=jackson
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class org.axonframework.serialization.UnknownSerializedType and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: java.util.ArrayList[0])
at com.fasterxml.jackson.databind.exc.InvalidDefinitionException.from(InvalidDefinitionException.java:77) ~[jackson-databind-2.12.5.jar:2.12.5]
at com.fasterxml.jackson.databind.SerializerProvider.reportBadDefinition(SerializerProvider.java:1276) ~[jackson-databind-2.12.5.jar:2.12.5]
at com.fasterxml.jackson.databind.DatabindContext.reportBadDefinition(DatabindContext.java:400) ~[jackson-databind-2.12.5.jar:2.12.5]
First of all, I have to ask why you want to use eventStore#readEvents given that this is not a common usage. This method is used internally by the Framework and most of the time, should be kept like that.
To your problem, you can easily check on Framework code what is happening and how it uses the eventStore#readEvents method.
First of all, the signature here: DomainEventStream readEvents(String aggregateIdentifier);
It returns a DomainEventStream which is an Iterator implementation of a DomainEventMessage (as you can also see on code: public interface DomainEventStream extends Iterator<DomainEventMessage<?>> {).
Checking any of the usages, for example the EventSorcingRepository, you can see how it is used here and here and pretty much use Iterator's method for that (hasNext and peek for instance).
Using those methods will give you access to the DomainEventMessage where you can get the Type but also the Payload (and other useful things you may need).
Hope that clarifies the usage of it but also make sure you really want to use it!

Data conversion pattern with Business Object, DTO and Entity/Domain Object

In my Spring boot project I use hibernate and basically we have three kinds of objects
DTO object which is used in the controller layer.
Business Object - business object is what we use throughout our application.
Entity/Domain Object - which is used in JPA layer.
When we are ready to save the data we turn the Business Object to Domain/Entity Obj
And when we are ready to send it to the client/controller we can convert the entity object to Business Obj and this Business object in turn to DTO Obj.
Ideally I was told that the conversion logic of changing BOs to -> (DTOs and entities) and vice versa reside in the BOs itself?
How do we achieve this in an efficient way? Can anyone help with any examples?
I love to use Mapstruct in all the projects that I am participate in
There are several things that I adore most about it:
Obviously, you spend less time on coding the conversions (have a look at 'MapStruct in 2 Minutes' on the main page)
If you the property names in your class that you want to transform to and from are the same then you write even less of code.
It integrates well with spring, so you don`t need to declare any beans or something, just specify that it is "spring" component model.
You have variety of ways how to map entities - create new, update existing with values from DTO(for example).
Children objects are easily mapped as well. It has internal mechanism that tries to pick up the right mapper method in other mappers. Or you can specify its name yourself arbitrary.
Though you can also have a look at ModelMapper as well. Pretty similar library, but less used by myself. So cannot make any particular advice.
There is no silver bullet for this task, but you can consider using model mapper for that; that's the simple example https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application

Realm Swift2: Best practice for model and Realm model class separation

I just have started working with Realm for Swift. After reading the documentation, still I have a couple of question marks in mind.
My biggest one is, if there is a best practice for separation Model classes from Realm classes.
For example, in Java MVC projects we used DAO classes (Data Access Object classes) which were responsible for the communication with the database layer.
Our corresponding model classes only have either the dao object injected or we used service classes for this (like CRUD operations).
If I habe a Realm “Model” class, this seems now to be everything in one. But after having the object persisted to the database, changing attributes of the object in the UI-Layer results in
'Attempting to modify object outside of a write transaction - call
beginWriteTransaction on an RLMRealm instance first.'
Which brings me back to my initial though: Shouldn’t this be separated in Realm objects and model objects. Or is it OK to have "realm.write" processes in View-Classes then?
I did some research on this but the results are very vage on this.
How do you deal with this in your projects. Do you have some kind of best practice or guidance?
Many thanks in advance
John
Officially, (on the iOS side at least), there's no established best practice for abstracting the model class logic away from the actual Realm Object subclasses. That being said, I've definitely heard of apps in the past who do do this sort of logic in order to support multiple types of data frameworks.
If I were to do this, I would make a separate object class for each model implementing my own API on how to get/set data properties, and make the Realm object an internal member of this object. This object would then serve as the generic interface between my app's logic and how to save that data to Realm. That way, if I did want to swap out the data framework down the line, I could simply replace my own data object with a new one, but keep the API consistent.
In regards to that error message you posted, in order to ensure data integrity, you cannot modify a Realm object (UI thread or otherwise) unless it's in a write transaction. That being said, you could encapsulate that logic (i.e. open up a Realm write transaction on the current thread) pretty easily within that abstract object.

How to correctly use Spring Data Repository#save()?

In Spring Data Repository interfaces, the following operation is defined:
public T save(T entity);
... and the documentation states that the application should continue working with the returned entity.
I know about the reasoning behind this decision, and it makes sense. I can also see that this works perfectly fine for simple models with independent entities. But given a more complex JPA model with lots of #OneToMany and #ManyToMany connections, the following question arises:
How is the application supposed to use the returned object, when all the rest of the loaded model still references the old one that was passed into save(...)? Also, there might be collections in the application that still contain the old entity. The JVM does not allow to globally "swap" the unsaved entity with the saved one.
So what is the correct usage pattern? Any best practices? I only encountered toy examples so far that do not use #OneToMany or #ManyToMany and thus don't run into this issue. I'm sure that a lot of smart people thought long and hard about this, but I can't see how to use this properly.
This is covered in section 3.2.7.1 of the JPA specification that describes how merge should work. In a nutshell, if the instance being saved is managed (existing), it is simply saved in-place. If not, it is copied to a managed instance (which may not necessarily be a different object since the spec does not mandate that a new instance must be created in this case) and all references from the instance being saved to other managed entities are also updated to refer to the managed instance. This of course requires that the relationships have been correctly defined from the entity being saved.
Indeed, this does not cover the case of storing an entity instance in an unmanaged collection (such as a static collection). That is anyways not advisable because a persisted entity must always be loaded through the persistence provider mechanism (who knows the entity instance may have changed in the persistent store).
Since I have been using JPA for the past many years and have never faced problems, I am confident that the section I have referenced above works well in all scenarios (subject to the JPA provider implementing it as intended). You should try some of the cases that worry you and post separate questions if you run into problems.

Trying to improve efficiency of MVC3 + Unity project

I have an MVC3 project that uses Unity for dependency injection.
There is a main MVC3 project, a “domain” class library that sits between MVC3 and the data tier, and a bunch of class libraries that make up the data tier.
(MVC3) – (domain) – (data tier)
This is an example of one of the service constructors in the domain class:
public DomainModelCacheServices(
Data.Interface.ICountryRepository countryRepository,
Data.Interface.ILanguageRepository languageRepository,
Data.Interface.ISocialNetRepository socialNetRepository
)
Every time a controller is called that has DomainModelCacheServices in its constructor, a new DomainModelCacheServices object is constructed, plus the three repository classes in the constructor of DomainModelCacheServices.
I cannot believe this is efficient!
What makes this worse is that the class DomainModelCacheServices is a cache class. It loads lists of data that never change, and holds them as statics. But it still needs to construct three repository classes for every reference!
If I give DomainModelCacheServices the lifetime of a singleton (forever), I have to ensure it is thread-safe, and if the day comes when I am getting hundreds of hits, there’s going to be a lot of locking.
I could change the constructor to this:
public DomainModelCacheServices(
IServiceLocator serviceLocator
)
I don’t know why, but this doesn’t look right. The constructor becomes meaningless to the eye, and I have to reference Unity in the domain class and somehow make the domain class aware of the ServiceLocator owned by the MVC3 application. Maybe the loose-coupling can be too loose?
Maybe constructing all these classes is not as inefficient as it looks I shouldn’t worry about it?
What would be nice is if Unity supported “Lazy” constructor parameters. But it doesn’t.
So, any ideas on how to make an MVC3 + Unity project more efficient, specifically in the domain model design?
Thanks for reading!
The cache shouldn't be definied on the domain level but on the repositories implemntation level (so in DAL). So for example ICountryRepository should have two implementations in DAL : CountryRepository and ChachedCountryRepository. These should be wired as decorators in Unity (CountryRepository is inside the ChachedCountryRepository). CachedCountryRepository would check if the data is in the cache and if not it would pass the call to the inner CountryRepository.
Creating objects is not expensive and wouldn't care too much about issues as a caching is correctly definied.
Great reasoning.
However, creating objects is cheap. I would not create a singleton since you already are caching all objects in static fields. The current approach is easy to understand.
I got another question for you:
Why are you not caching in your repository classes?
The repositories are responsible for the data and all data handling should be transparent to everything else. It also makes everything easier since they are responsible of updating the data sources. How do you keep the cache in sync with changes today? Through domain events?
I would create a cache class which I would use as a private field in the repository.

Resources