search

blynkkk / blynk-library

Blynk library for IoT boards. Works with Arduino, ESP32, ESP8266, Raspberry Pi, Particle, ARM Mbed, etc.
https://blynk.io
MIT License
3.81k stars 1.38k forks source link

Hardcoded BLYNK_TEMPLATE_ID and BLYNK_TEMPLATE_NAME #589

Closed adamCPP closed 10 months ago

adamCPP commented 11 months ago

In version 1.3 you added in BlynkApi.h

if !defined(BLYNK_TEMPLATE_ID) || !defined(BLYNK_TEMPLATE_NAME)

#error "Please specify your BLYNK_TEMPLATE_ID and BLYNK_TEMPLATE_NAME"

endif

Before this i have used Blynk with just BLYNK_AUTH_TOKEN obtained during the runtime of the app and it worked. Please consider to not force users to hardcode this value before compilation.

Scenario, steps to reproduce

Compile app with Blynk without hardcoded BLYNK_TEMPLATE_ID and BLYNK_TEMPLATE_NAME

Expected Result

Compilation succesful

Actual Result

Preprocesor stops compilation process

CyberSteve99 commented 10 months ago

I have the same issue. I have had to hard code using version 1.2.0 due to this breaking change.

ram-codeswork commented 10 months ago

i cant fiqure this out still i tried even with 1.2.0 but it didnt work any idea?????/

vshymanskyy commented 10 months ago

This is required with Blynk 2.0, there's no big deal in hard coding it - it binds your firmware to the specific template or product, which makes sense.

CyberSteve99 commented 10 months ago

"No big deal" is an opinion that someone well versed in coding & development may have. For the less experienced it can be a big deal to diagnose why suddenly after many years (5+) their project no longer compiles and generates this error. The examples they based their code on no longer just work.

I suspect that many would not get in to the intricacies of lib dependencies and just let the development platform do what it does and bring in latest versions of libraries. To aid this ideally libraries should be backwards compatible. Maybe making the requirement for BLYNK_TEMPLATE_ID and BLYNK_TEMPLATE_NAME dependant on whether BLYNK_AUTH_TOKEN is defined or make the decision in the code dependant on what is defined might make it backward compatible.

Breaking changes are just that and require changes and there could be millions of projects out there that will no longer compile. I just think breaking changes should be avoided wherever possible.

However, your code, your choice and given future direction there may be good reason to disenfranchise use of older code and to optimise the library for the future direction that you don't have the choice to avoid breaking changes.

Cheers.

vshymanskyy commented 10 months ago

We added these checks for a purpose, and if you omit to add this info, your sketch will fail to work in the future. Your "fix" to downgrade the library is not viable so I removed the suggestion, not to confuse other users.

You just need to include BLYNK_TEMPLATE_ID and BLYNK_TEMPLATE_NAME when you upgrade your sketch, this is well known and well documented.