Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Sam Bosley
@sbosley
or you can define java methods for common tasks at the application level
maybe if you give me a more concrete example of the task you're trying to accomplish I can help with other suggestions
ujagarsingh
@ujagarsingh
thank you so much @sbosley for helped us. i give you task detail if i have some problem and not resolved as your suggestion.
Sam Bosley
@sbosley
:+1: sounds good!
John L. Jegutanis
@erasmospunk
Hello. I am using a shared "core" library that is shared between android and ios.
I wanted to include the squidb + annotations without the squidb-android in the core library and include it in the android project.
Unfortunately I get errors that go away if I add all the related squidb dependencies to the android project and remove everything from the core library.
Is there a way around it?
Sam Bosley
@sbosley
Hi @erasmospunk, what you describes sounds like the right concept of setup, so you might need to share more details of the specific error you're seeing. but generally yes, you should create a core library that depends on squidb and squidb-annotations. then your android code depends on core and squidb-android, and your iOS code depends on core and squidb-ios.
without having any further details this is just a wild guess, but did you declare the dependencies in code using api instead of implementation? I believe that only dependencies declared with api will become part of the public api of a shared module
bhavdipb
@bhavdipb

Hi Everyone,,

I am facing one issue and not able to configure squidb with sample project also

/Users/xxxxxxxx/Downloads/squidb-master/squidb-ios/src/com/yahoo/android/sqlite/SQLiteDatatypeMismatchException.java:19: cannot find symbol
symbol: class SQLiteException
Please let me know
Abdul Wadood
@abdulwd
Hi, I just want to know if squidb performs queries on background thread by default or not on Android. Thanks!
MFlisar
@MFlisar
Currently still using squidb v3, but I have one suggestion: I like to split up my projects in modules for android and I always create a db module. I would like to hide all squidb code in there, but I have a problem. If I define public interfaces in my core module and want to expose setters, I always need to define setters with the return type of TableModel. Would it be possible to disable this queuing supporting setters and instead only create setters with void return types? This way, I would not need to write extra setters to hide the complete squidb classes within one module nor to write extra setters with void return value...
MFlisar
@MFlisar
I solved this by simply building squidb from source and adjust the BasicPropertyGenerator accordingly...
Sam Bosley
@sbosley
@MFlisar
No easy wa
No easy way without a plugin, but what about defining your interface to use a return type that’s your interface instead of TableModel? I would think that would work since the return type of the setters should be the actual class type
@abdulwd
No, queries and other db ops are synchronous. Threading choice is left up to the caller — you could use async tasks, thread pools, rx, whatever makes most sense for your app
MFlisar
@MFlisar
@sbosley totally correct, but if you're using kotlin and define interface variables like var data1: String you will get void setters/getters, using custom return types means extra work on this side, but still you're right
Additionally, kotlin is not yet supported by yur processor, is it? E.g. static function are defined in a companion object in kotlin. If I defineModelMethods there, those are not converted to class functions correctly... Can try this again, if you want to know the concrete problem (I think it was that those methods stayed static methods...)
MFlisar
@MFlisar
I would have some suggestion for a very useful plugin: I think it makes sense to hide database code in a module (in android) or in some other private package e.g. so that the final implementation is hidden from the code that uses the database classes. Would it be possible to enable generating interfaces for each data model? This would be very handy for this use case...
Sam Bosley
@sbosley
@MFlisar as to your first question, that's correct, there's nothing in the processor (or any part of squidb, really) that does anything special for kotlin. as to your second question, sure, you could write a plugin that used the declareAdditionalJava hook to generate an entirely new file based on the properties in the model spec. I'm not sure that I see too much value in this though -- an interface abstracts away implementation details so that multiple different implementations can be provided. in this case, there would be a 1-1 correspondence between the interface and its implementation, since a squidb model is really just a data transfer class. any alternative implementation wouldn't be accepted by the squidb database classes (since it expects AbstractModel etc.)
plus, the interface would be tightly coupled to the processor generating it, so it wouldn't be of much help in abstracting away data models for switching to other data layers either
or maybe you have some use case in mind I haven't thought of?
MFlisar
@MFlisar
My main purpose of the interface abstraction is modularisation and compile time optimisation. Writing a database module, then generating the interface in a minimal core module und using the interface in the ui and some other modules has the big advantage, that non of my other modules have any dependency on any database code... E.g. I have a highly customisable app with hundreds of settings, I have a ui module, a settings module, a image loading module and all of them use the common data interfaces... Second good thing here is, that annotation processors are slowing down compile time as well, moving them to small modules that don't change often can improve compile time as well...
Secondly, is kotlin support planned? I use extension functions that only work in kotlin, so kotlin support would be nice for me...
Sam Bosley
@sbosley
@MFlisar I don't have nearly enough kotlin expertise to be able to do anything special in the annotation processor, but according to this doc, annotation processing should "just work" in most cases. which makes sense, it's really the responsibility of the compiler to present to the annotation processor a consistent view into the code being compiled. the annotation processor is very limited by what the compiler provides to it. you mentioned some kind of issue with static methods in companion objects; did you annotate them with @JvmStatic as is documented there?
MFlisar
@MFlisar
You're right. I will test the annotation. Thanks
tomerpetel
@tomerpetel
Hi All, a quick question regarding Squidb security. I want to store some sensitive data in my DB and wonder how can I secure it? Should/can I use SQLCipher for instance or does Squidb has some other way? Thx :)
Sam Bosley
@sbosley
Hi @tomerpetel, good question. we had looked at introducing support for SQLCipher several years back, but at the time they were based on outdated/buggy versions of the android SQLite classes, so were deemed incompatible. it looks like in the years since they may have updated their code, so it is possible that it would work now, but I haven't tried it. if you wanted to give it a try, your goal would be to provide implementations of ICursor, ISQLiteDatabase, ISQLitePreparedStatement, and ISQLiteOpenHelper that wrap the corresponding SQLCipher classes. This is usually a pretty direct wrapping; you can find examples of an implementations here, which are the wrappers for the android SQLite bindings project: https://github.com/yahoo/squidb/tree/master/squidb-addons/squidb-sqlite-bindings/src/com/yahoo/squidb/sqlitebindings. then you just override createOpenHelper in your database to return your SQLCipher implementation, similar to how its documented here: https://github.com/yahoo/squidb/wiki/Using-a-custom-SQLite-build
if you decide to try this, I highly recommend you clone and run the full squidb unit tests with your SQLCipher wrappers enabled, since our test cases should verify whether or not they've updated to newer source that fixes the problems we were seeing
your other option is to pay for a license for the official SQLite encryption extension, but I do not know if they support android or not: https://www.sqlite.org/see/doc/trunk/www/readme.wiki
basically, all security of the type you're talking about would happen below the squidb level, since squidb is just a layer on top of the existing SQLite android classes. so if any of these encryption solutions have low-level SQLite access classes based on the android SQLite classes from v14 or higher, then in theory it should be possible to write the adapters to plug them into squidb
MFlisar
@MFlisar
Are you planning to support immutable models in the future? I currently always clone my models and adjust their attributes and push them back in a redux like store and if I forget to clone my model and adjust it directly this results in quite some problems, so it would be really nice to be able to create immutable models...
tomerpetel
@tomerpetel
@sbosley, I'll be glad to give it a try but later on (Q1 2019 hopefully). I'll sure need some guidance so expect some more questions :).